This change adds predicates to check whether a given JavaScript operator
needs the "current context" or if any surrounding context (including the
"native context") does it. For example JSAdd doesn't ever need the
current context, but actually only the native context. In the
BytecodeGraphBuilder we use this predicate to check whether a given
operator needs the current context, and if not, we just pass in the
native context.
Doing so we improve the performance on the benchmarks given in the
tracking bug significantly, and go from something around
arrayMap: 476 ms.
arrayFilter: 312 ms.
arrayEvery: 241 ms.
arraySome: 152 ms.
to
arrayMap: 377 ms.
arrayFilter: 296 ms.
arrayEvery: 191 ms.
arraySome: 91 ms.
which is an up to 40% improvement. So for idiomatic modern JavaScript
which uses higher order functions quite a lot, not just the builtins
provided by the JSVM, this is going to improve peak performance
noticably.
This also makes it possible to completely eliminate all the allocations
in the aliased sloppy arguments example
```js
function foo(a) { return arguments.length; }
```
concretely we don't allocate the function context anymore and we also
don't allocate the arguments object anymore (the JSStackCheck was the
reason why we did this in the past, because it was holding on to the
current context, which also kept the allocation for the arguments
alive).
Bug: v8:6200, v8:8060
Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef
Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators
Reviewed-on: https://chromium-review.googlesource.com/c/1267176
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56441}
On windows, the {NativeModule::committed_code_space_} counter can underflow because
of a bug. This propagates to {WasmCodeManager::remaining_uncommitted_code_space_},
which can lead to over-allocation (more than {kMaxWasmCodeMemory} bytes of code
space per module).
We were also seeing this bug on UMA data (>1024 MB code space usage).
R=ahaas@chromium.org
Bug: chromium:893096
Change-Id: If3c9b3e7bdc9fc3caf1eccae991123409718b90f
Reviewed-on: https://chromium-review.googlesource.com/c/1267943
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56440}
This is a reland of ef2a19a211.
Use AllocateJSArray to avoid allocating an empty fixed array.
Original change's description:
> Add fast path for spreading primitive strings.
>
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
>
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
>
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}
Bug: chromium:881273, v8:7980
Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3
Reviewed-on: https://chromium-review.googlesource.com/c/1267497
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56438}
When generating code for element accesses, we used to constant-fold
JSTypedArray receivers even when their buffers were on the JS heap.
This required a call to MaterializeArrayBuffer, which hinders
background compilation. Since the benefit of this optimization is
believed to be small, we decided to remove it.
Bug: v8:7790
Change-Id: I28d3a57b3d8f5b58b6e00e0bb8328b682a6fbd88
Reviewed-on: https://chromium-review.googlesource.com/c/1256831
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56434}
Return the actual length even when the buffer is neutered (we used
to return 0). This avoids confusion and makes the behavior consistent
with byte_offset() and byte_length().
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I998f12fa4a428f8555f62e1535247f571ab053f2
Reviewed-on: https://chromium-review.googlesource.com/c/1256768
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56433}
In the JSCallReducer, the lowering for Array#filter(), Array#some() and
Array#every() properly converted the outcome of the predicate call to
boolean using the ToBoolean conversion, but then also added a redundant
ReferenceEqual comparison with true. This particular pattern is not
optimized by TurboFan, since it can never happen using the regular
comparison machinery. So remove the unnecessary ReferenceEqual and just
do the ToBoolean in the JSCallReducer.
Bug: v8:8238
Change-Id: Ic2585431b4b75d3d5f978c85156cfb19738b7ae6
Reviewed-on: https://chromium-review.googlesource.com/c/1267177
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56430}
As identified in the web-tooling-benchmark, there are specific code
patterns involving array indexed property accesses and subsequent
comparisons of those indices that lead to repeated Smi checks in the
optimized code, which in turn leads to high register pressure and
generally bad register allocation. An example of this pattern is
code like this:
```js
function f(a, n) {
const i = a[n];
if (n >= 1) return i;
}
```
The `a[n]` property access introduces a CheckBounds on `n`, which
later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
however the `n >= 1` comparison has collected `SignedSmall` feedback
and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
second Smi check is redundant and cannot easily be combined with the
earlier tagged->int32 conversion, since that also deals with heap
numbers and even truncates -0 to 0.
So we teach the RedundancyElimination to look at the inputs of these
speculative number comparisons and if there's a leading bounds check
on either of these inputs, we change the input to the result of the
bounds check. This avoids the redundant Smi checks later and generally
allows the SimplifiedLowering to do a significantly better job on the
number comparisons. We only do this in case of SignedSmall feedback
and only for inputs that are not already known to be in UnsignedSmall
range, to avoid doing too many (unnecessary) expensive lookups during
RedundancyElimination.
All of this is safe despite the fact that CheckBounds truncates -0
to 0, since the regular number comparisons in JavaScript identify
0 and -0 (unlike Object.is()). This also adds appropriate tests,
especially for the interesting cases where -0 is used only after
the code was optimized.
Bug: v8:6936, v8:7094
Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
Reviewed-on: https://chromium-review.googlesource.com/c/1246181
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56428}
This reverts commit 4fd92b252b.
Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots)
Original change's description:
> [turbofan] Do not consume SignedSmall feedback in TurboFan anymore.
>
> This changes TurboFan to treat SignedSmall feedback similar to Signed32
> feedback for binary and compare operations, in order to simplify and
> unify the machinery.
>
> This is an experiment. If this turns out to tank performance, we will
> need to revisit and ideally revert this change.
>
> Bug: v8:7094
> Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
> Reviewed-on: https://chromium-review.googlesource.com/c/1261442
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56411}
TBR=jarin@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7094
Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404
Reviewed-on: https://chromium-review.googlesource.com/c/1267175
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56427}
Use bits flag for caseFirst, hourCycle and numeric in Locale.
Also set up macro for V8_INTL_SUPPORT only in heap-symbols.h
Bug: v8:7684, v8:8256
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I3f6956b6dd5782e88676667381a7d8a7b2476bfc
Reviewed-on: https://chromium-review.googlesource.com/c/1262476
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56423}
- Exposes IsSupportedVersion function which compares serialized
version to current Wasm version.
- Tweaks the comments on serialization to match the code.
Bug: chromium:719172
Change-Id: I76df9605aee16fd98cd82b54dba2e9acbd56b41b
Reviewed-on: https://chromium-review.googlesource.com/c/1265141
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56420}
The RNG state is initialized with random_seed parameter that usually
has lots of zeros. Each random generation iteration shuffles bits with
xor operation over the state. It takes a while before the state is populated
with enough 1s and starts generating uniformly distributed numbers.
The patch warms up the state with 32 iterations when --random_seed is used.
BUG=v8:8265
Change-Id: I7a4e8c842962bea0f2935c7b3673494367d8580f
Reviewed-on: https://chromium-review.googlesource.com/c/1263816
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56418}
Previously, bootstrapper.cc contained a mixture of approaches:
- NewStringFromAsciiChecked("foo"): 40 matches
- NewStringFromStaticChars("foo"): 4 matches
- InternalizeUtf8String("foo"): 55 matches
The most common use case for any of these in the bootstrapper is
to represent property names. For those, we eventually need internalized
strings anyhow. E.g. NewStringFromAscii causes an InternalizeString
call later, possibly creating a copy or ThinString.
This patch uses InternalizeUtf8String where it makes sense to do so.
https://chromium-review.googlesource.com/c/v8/v8/+/1253603/1/src/bootstrapper.cc#2098
Bug: v8:8238
Change-Id: I124607988b75449d7f78d5933657c35b532bd1c9
Reviewed-on: https://chromium-review.googlesource.com/c/1255727
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56417}
This forces .generator_object variable to stack slot 0 for async
generator functions so that the stack trace construction logic
can extract the JSAsyncGeneratorObject appropriately.
Bug: v8:7522
Change-Id: I37b52836bb512bcf5cd7e10e1738c8e7895b06ea
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264556
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56415}
GCC 4.9.2 on MIPS generates a reference to OFStreamBase()
d8.cc. In debug mode OFStreamBase is local to libv8_base and
linking fails.
Change-Id: I93bb93d03a4cc81c59f94cf2168c92557845e87d
Reviewed-on: https://chromium-review.googlesource.com/c/1258903
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#56413}
For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.
Some drive-by cleanups:
- Remove the switch in NameForRuntimeId() and just use the table of
runtime functions to lookup the name directly.
- Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
they are the last users of the inline versions of these.
- Remove the MaxSmi inline version as it is only used in tests.
Saves 64 KiB binary size.
Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
This changes TurboFan to treat SignedSmall feedback similar to Signed32
feedback for binary and compare operations, in order to simplify and
unify the machinery.
This is an experiment. If this turns out to tank performance, we will
need to revisit and ideally revert this change.
Bug: v8:7094
Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
Reviewed-on: https://chromium-review.googlesource.com/c/1261442
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56411}
This cuts down the perf cost on Octane from 18% to 13%. The baseline is the no mitigation
Octane score, the array access mitigation cost was about 4%. This means we would be
getting a bit more than 1/3 of the poisoning regression back.
Bug: chromium:856973, chromium:887213
Change-Id: Ibd99f66ae832c6080f2c2e5b33a1a7610907466f
Reviewed-on: https://chromium-review.googlesource.com/c/1251401
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56409}
Move the entry-point for destructuring assignment out of the recursion so we
can avoid swapping ASSIGNMENT scope to ASSIGNMENT_ELEMENT.
Also rewrite Assignment directly without wrapping in RewritableExpression
first.
Change-Id: Iae768ad1b2a6fb40ce37142867d7034f924354e4
Reviewed-on: https://chromium-review.googlesource.com/c/1264284
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56406}
After rewriting a rewritable assignment expression we possibly add the
resulting do-expression in two places: the rewritten expression and the parent
block. That would observably generate duplicate code. Luckily this can't happen
since the only recursive paths that would call this function again change the
context to ASSIGNMENT_ELEMENT from ASSIGNMENT. Hence simply DCHECK_NULL(block_)
and reset it to nullptr at the end.
Change-Id: I17b84dedcd7daf800d9ccb90e3dd975e84b12717
Reviewed-on: https://chromium-review.googlesource.com/c/1264282
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56404}
var declarations that walk through with scopes are special in that the variable
will always end up in the outer declaration scope, but the initializer for the
var will possibly target the with scope. Hence we can't simply use the resolved
variable proxy from the declaration for the initialization. However, if we know
that the var declaration lives in the scope where it will be declared (the
common case), there can't be a with scope in between. Hence we are free to
reuse the proxy.
Change-Id: I434abcd5df1a44313a8b8da3303cf5748299de4b
Reviewed-on: https://chromium-review.googlesource.com/c/1261450
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56403}
When parsing an identifier as an expression we'll immediately create an
unresolved VariableProxy in the parsing scope. If this variable ends up
becoming a declaration, e.g., due to arrow function parameter, we'll move it
into the function scope for that arrow function. Then to actually create the
declarations we rewrite the "pattern". When we declare the variable, the proxy
is automatically resolved to the variable we create from it. That means it
can't be in the unresolved list anymore.
We tried to remove the unresolved variable. Unfortunately, if there was a
sloppy eval in a parameter context, there's an additional var-block scope
created for the parameter. Rewriting happens in *that* scope. Hence we didn't
always manage to remove the unresolved variable. I suppose as a fix an
additional variable proxy was introduced; since otherwise the implicit
resolution upon declaration would trigger a dcheck in scope resolution later.
This CL removes the initial variable proxy from the correct scope, so it can be
reused for the declaration.
Change-Id: Id917afb177aef076a2947b0fdd03b5393bd29c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1261937
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56402}
These functions got replaced the the taskrunner API. The new way to
post tasks is as follows:
v8::Platform* platform = ...; // e.g. V8::GetCurrentPlatform();
v8::Isolate* = ...;
std::shared_ptr<v8::TaskRunner> taskrunner = platform->GetForegroundTaskRunner(isolate);
std::unique_ptr<v8::Task> task = ...;
taskrunner->PostTask(std::move(task));
R=ulan@chromium.org
Bug: v8:8238
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I44a70fc530daae581ee31e54fd09e776ba648406
Reviewed-on: https://chromium-review.googlesource.com/c/1261936
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56400}
- Get rid of an unnecessary call to uloc_canonicalize in js-locale.
- Do not use regex, but rely on ICU for the structrural validity check
with Chrome's ICU or ICU 63 or newer. Otherwise, continue to use regex.
This became possible thanks to a couple of bug fixes in ICU ToT that
were cherry-picked for Chromium's ICU.
Not yet done is to change js-locale to use CanonicalizeLocale().
That will make a few more tests pass.
Bug: v8:8135
Test: test262/intl402/Intl/getCanonicalLocales/*
Test: test262/intl402/Locale/*
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I45c10b298fb041e0b39a4d96309c68a7966f91c2
Reviewed-on: https://chromium-review.googlesource.com/c/1215223
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56399}
For --async-stack-traces don't try to peak into frames that don't belong
to async functions/generators, specifically don't try to peak into some
arbitrary builtin frames (the FrameInspector doesn't support that).
Bug: chromium:892472, chromium:892473, v8:7522
Change-Id: Idcdee26ff958c03b24dd2910bb92fc51cbc14e3c
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264276
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56396}
The CheckSmi in String.fromCodePoint() is unnecessary and even leads to
unnecessary deoptimizations, since the CheckBounds already does the
right thing, plus it also handles HeapNumbers (in Signed32 range) and
properly identifies zeros.
Bug: v8:8238
Change-Id: I73bf7a70c3cd718c987f112ceb928188c0534cd5
Reviewed-on: https://chromium-review.googlesource.com/c/1262675
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56395}
Remove -Wexit-time-destructors warnings which triggered when global
objects cause destructors to be run at exit time.
Bug: v8:8257
Change-Id: I8407f1936cd6d13a2e30f55cfb4907a99ccca033
Reviewed-on: https://chromium-review.googlesource.com/c/1259863
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56388}
Long time ago there were two passes over heap. One was counting
objects and edge and another was filling them. Since then we have
just a single pass, but the filler object is still there.
Remove it for the sake of layering simplicity.
Reviewed-on: https://chromium-review.googlesource.com/1244380
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56246}
TBR=ulan@chromium.org
Change-Id: Ie155a79f7aaf9b2612ae89f67b793ba813c364c9
Reviewed-on: https://chromium-review.googlesource.com/c/1261882
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56387}
Port b048c16b4f
Original Commit Message:
The goal is to remove CL to remove the confusing implications for
full poisoning.
This is an alternative to
https://chromium-review.googlesource.com/c/chromium/src/+/1253341
where chrome has to work around our implication system.
In the optimizing compiler, we already have a bottleneck for setting
mitigation level in src/compiler/pipeline.cc, so it is easy to change
back to partial mitigations.
R=jarin@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I96d0651eed2638abddb5486da1e2b55a84e97264
Reviewed-on: https://chromium-review.googlesource.com/c/1261797
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56385}
Holes in double arrays are encoded using a signaling NaN bit pattern.
Previously when checking for Float64 holes we did an expensive bit
check always, but most values aren't even NaNs in reality. So we changed
the CheckFloat64Hole operator to first check if the value is a NaN at
all and only if so, perform the concrete bit check (in deferred code).
This improves the array copying test case mentioned in the bug from
copyPacked: 123 ms.
copyHoley: 157 ms.
to
copyPacked: 122 ms.
copyHoley: 125 ms.
so there's almost no penalty for double holey arrays anymore in case of
copying arrays. This change seems to yield an overall ~1% on the Kraken
benchmark.
Bug: v8:8264
Change-Id: Id7393867ec96fdc080e24d326039f80a9d7b6646
Reviewed-on: https://chromium-review.googlesource.com/c/1261519
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56380}
AtomicPair operations are only available with some instructions
introduced in version R6. Add support for needed instructions.
Change-Id: I808d6ed5b5efafd638846ec599941ebc71d90e23
Reviewed-on: https://chromium-review.googlesource.com/c/1251526
Reviewed-by: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#56379}
We want to replace all uses of CallOnForegroundThread eventually by the
new TaskRunner API so that we can eventually deprecate the old API and
remove it.
R=ulan@chromium.org
Bug: v8:8238
Change-Id: I7e451eddf05f1f7f273c5cfd57d82737380f3f02
Reviewed-on: https://chromium-review.googlesource.com/c/1261145
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56378}
