... in favor of CodeAssembler's ScopedExceptionHandler.
Also remove unused exception arguments from some iterator
related methods.
Bug: v8:10187
Change-Id: I8eb7dfd4eb339e4f566970efa5757c3771926ba6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060496
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66306}
This adds tests for the mock logic used in differential fuzzing. The
tests uncovered a couple of issues in the mock files that are also
fixed.
This also does some minor code clean up in the mock code.
Bug: chromium:1044942
Change-Id: I5b67f70f8b104bb681548f742ab863395a88360f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043843
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66304}
This CL reinstates the old pow implementation which calls out to the
system implementation of pow.
Bug: v8:9622
Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66303}
REPL 'let' declared variables use VariableLocation::REPL_GLOBAL which
was not handled by a switch in the bytecode generator. The default
case ran into an UNREACHABLE.
This CL fixes this by properly handling VariableLocation::REPL_GLOBAL
for delete.
Drive-by: Replaced the default case with an explicit case for
VariableLocation::MODULE.
Bug: chromium:1052721
Change-Id: I1330ff2f2c6f042a596a8298599a5d58769894f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060488
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66301}
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex,
we get back one bit that we can use to increase the number of hash bits
stored. The price is that strings that represent array/integer indices
beyond the cacheable range will have to be scanned more often, but these
strings should be rare, and we expect that the additional hash bit is
more worthwhile to have.
Bug: v8:9904
Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66299}
Implement the latest spec changes:
- Allow declarative segments to behave like passive & dropped segments.
- Enforce that only declared functions may be returned or used in globals
as funcref.
- Ensure that table fill does not modify any entries if OOB.
Spec tests for select and br_table are still failing due to proposal issue
Bug: v8:10156
R=ahaas@chromium.org
Change-Id: I5b95be36a67bc7482a84b848908cc4cbdf94af03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027458
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66297}
Intl.RelativeTimeFormat constructor crash while the locale or
numberingSystem contains an "algorithmic" numberingSystem.
Fix by fallback to the locale without the nu
Bug: chromium:1041319
Change-Id: Ica520e8dec6ace21264504274b92cb2c3d16286f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055970
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66276}
Since the size of the parameters and locals inputs is already stored on
the FrameStateFunctionInfo, this skips the calls to size() and just
reuses the previous values. The stack parameter can only have a size of
0 or 1 depending on whether it's a InterpretedFunction frame or not.
It also extends the verifier to check that the values to match those
returned by StateValueAccess::size and changes a unit test that added
a TypedStateValues of size 2 to the stack input.
Bug: v8:10051
Change-Id: I3693c04b4677812b9f19491c198d0551df20f817
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047045
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66268}
The previous code was relying on {compilation_unit_builder_} to check if
a section was after or before the code section. This only works for the
first section after code section, since the compilation unit builder is
then reset. Use an additional field to track this instead.
R=clemensb@chromium.org
Bug: chromium:1051912
Change-Id: Id1dfa803ecde2cf77f206ea781c007fc61168942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054099
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66265}
These tests are likely missing %PrepareFunctionForOptimization
annotation of lambdas. Thus lambdas are no longer inlined and
%DeoptimizeNow does nothing, while the entire point of these tests is
to test deoptimization paths.
Disabling lazy feedback allocation is a quick fix to restore coverage
until we can land a more complete fix (for details see the linked
bug).
Bug: v8:10195
Change-Id: I4038cdc5718230253ffb5bbc57d574342c652377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054096
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66261}
The fix in b8b6075021 was insufficient.
The bug is that induction variable typing does not take into account
that the value can become NaN through addition or subtraction of
Infinities. The previous fix incorrectly assumed that this can only
happen when the initial value of the loop variable is an Infinity.
Bug: chromium:1051017
Change-Id: I8c9ffb2925288b80c00e18e7bc22a556bf540733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051957
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66258}
This is a reland of 137bfe47c9
Original change's description:
> [arm64] Protect return addresses stored on stack
>
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack. The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
>
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
>
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
>
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}
Bug: v8:10026
Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#66254}
A FinalizationGroup that needs cleanup should not artificially prolong
its lifetime by being on the dirty list.
R=ulan@chromium.org
Bug: v8:8179
Change-Id: I19f102d154a9ac43b549b7d833d0c3ca7e61c6d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051562
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66251}
Fuchsia's SDK will soon provide GN rules include one for declaring
fuchsia package targets. Since the SDK-provided rule works differently
from the Chromium one but is called fuchsia_package(), we need to rename
the Chromium rule to avoid them clashing.
Bug: chromium:1050703
Change-Id: Ia2fcba8e32f311e6859590d9c95730ffe6875192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050388
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66244}
This reverts commit 137bfe47c9.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
Original change's description:
> [arm64] Protect return addresses stored on stack
>
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack. The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
>
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
>
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
>
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
This change uses the Arm v8.3 pointer authentication instructions in
order to protect return addresses stored on the stack. The generated
code signs the return address before storing on the stack and
authenticates it after loading it. This also changes the stack frame
iterator in order to authenticate stored return addresses and re-sign
them when needed, as well as the deoptimizer in order to sign saved
return addresses when creating new frames. This offers a level of
protection against ROP attacks.
This functionality is enabled with the v8_control_flow_integrity flag
that this CL introduces.
The code size effect of this change is small for Octane (up to 2% in
some cases but mostly much lower) and negligible for larger benchmarks,
however code size measurements are rather noisy. The performance impact
on current cores (where the instructions are NOPs) is single digit,
around 1-2% for ARES-6 and Octane, and tends to be smaller for big
cores than for little cores.
Bug: v8:10026
Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}
We were calling setup for both the setup and the run.
Bug: v8:10155
Change-Id: Id60df16ad8c98f443dc1b1a9a2155000999ab815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039431
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66234}
These tests rely on predictable opt & deopt timings. Also add the
--opt flag to tests to force optimization even in configurations that
contain the --no-opt flag.
Bug: v8:9972,chromium:1049982
Change-Id: Ic161d188ebfae9aaae6a160d365413abedfee5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050402
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66231}
This CL introduces, and turns on by default, compression for snapshots.
The compression is handled in SnapshotCompression, which is a new static
helper class for producing/consuming compressed SnapshotData.
To turn off snapshot compression (accomplished by removing calls of
Compress/Decompress) set the GN arg:
v8_disable_snapshot_compression = true
Bug: chromium:833361
Change-Id: If8abc3662e8473fbd0c94e443946fbea804a305e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846066
Commit-Queue: Sam Maier <smaier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66230}
It's not sufficient to reset only the modules on the current DFS path.
Bug: chromium:1050164
Change-Id: I00e5e12144ad70ac6371eea5e11590b72feaeecc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049853
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66229}
This fixes a bug in lazy deopts caused by calls to the callback function
in Array.prototype.reduce and reduceRight.
The deopt continuation expects the *next* iteration's index value but
we actually passed the current iteration's value.
The user-visible effect of this bug was that sometimes, an unexpected
additional call to the callback function would occur.
It was introduced by https://crrev.com/c/1934329.
Bug: v8:9972,chromium:1049982
Change-Id: Icfd2ef076209e20602f54d4662220e1d4c5d07ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66226}
The Object::SetElement and JSObject::GetElement were
the GC suspects.
Fixed: v8:9995
Change-Id: Ia1f794188f08f0e2543a88eb4dc7a8b06dcb3deb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050391
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66223}
Adds support for off-thread allocation to Script allocation and
line-end calculation.
This includes adding support for keeping/merging a script list on
the OffThreadIsolate, and adding syntactical support for logging
(in the future this could do actual logging).
Bug: chromium:1011762
Change-Id: Id90f2ad7458e90e06f6926f1fce7ef7a1ef50b3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046884
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66213}
Deprecate the following explicit FinalizationGroup APIs in favor of
automatic handling of FinalizationGroup cleanup callbacks:
- v8::Isolate::SetHostCleanupFinalizationGroupCallback
- v8::FinaliationGroup::Cleanup
If no HostCleanupFinalizationGroupCallback is set, then
FinalizationGroup cleanup callbacks are automatically scheduled by V8
itself as non-nestable foreground tasks.
When a Context being disposed, all FinalizationGroups that are
associated with it are removed from the dirty list, cancelling
scheduled cleanup.
This is a reland of 31d8ff7ac5
Bug: v8:8179, v8:10190
Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66208}
FunctionEntry StackChecks is one of the two cases where we generate a
StackCheck bytecode. In these cases, we do stack check against the js
limit (not to be confused with the real js limit). Their purpose is to
be able to interrupt the running code.
We can omit the FunctionEntry StackCheck by embedding its code into
the InterpreterEntryTrampoline builtin. We save one bytecode per
interpreted function.
This change has rippling effects for optimized code, as well as the
deoptimizer.
Bug: v8:10149, v8:9977, v8:9960
Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66206}
Introduce separate counters for young and old array buffer bytes. They
are used to keep the counter stable during sweeping when the array
buffer lists are moved to the concurrent thread for sweeping.
Bug: v8:10064
Change-Id: I0f11a634341873b4d21759c284c55beb26fe30a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045511
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66204}
This makes creating whitelisted runtime functions more permissive on
fuzzers (when --allow-natives-for-fuzzing is passed).
- Runtime functions with too few arguments are replaced with undefined.
- Superfluous arguments are ignored.
This reduces syntax-error rate on fuzzers. Also prevents
dcheck errors when fuzzing debug builds and fuzzers use too many
arguments for runtime functions.
Bug: chromium:1044942
Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66202}
Update external memory counters when using ArrayBufferExtensions. In
case the array buffers are swept concurrently, the counters are updated
at the beginning of the next minor/full GC. A subsequent GC is going
to update counters faster.
ArrayBufferExtension now stores the accounting_length such that
the sweeper always knows how much memory to deduct from the external
memory on destruction.
ArrayBufferList now also tracks the size of all ArrayBuffers in it.
Bug: v8:10064
Change-Id: I50a8b1180aa837b6932f834df1610255bd2bd9fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041441
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66195}
This reverts commit 31d8ff7ac5.
Reason for revert: https://crbug.com/v8/10190
Original change's description:
> [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8
>
> Deprecate the following explicit FinalizationGroup APIs in favor of
> automatic handling of FinalizationGroup cleanup callbacks:
> - v8::Isolate::SetHostCleanupFinalizationGroupCallback
> - v8::FinaliationGroup::Cleanup
>
> If no HostCleanupFinalizationGroupCallback is set, then
> FinalizationGroup cleanup callbacks are automatically scheduled by V8
> itself as non-nestable foreground tasks.
>
> When a Context being disposed, all FinalizationGroups that are
> associated with it are removed from the dirty list, cancelling
> scheduled cleanup.
>
> Bug: v8:8179
> Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66184}
TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8179
Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66190}
If both isolates run this test, they are kind of racing on the
{tier_down_} flag, hence you get unexpected results.
Bug: v8:10189, v8:10099
Change-Id: I8657c32c024898442d5c916cf15077c846276b1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044544
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66188}
Deprecate the following explicit FinalizationGroup APIs in favor of
automatic handling of FinalizationGroup cleanup callbacks:
- v8::Isolate::SetHostCleanupFinalizationGroupCallback
- v8::FinaliationGroup::Cleanup
If no HostCleanupFinalizationGroupCallback is set, then
FinalizationGroup cleanup callbacks are automatically scheduled by V8
itself as non-nestable foreground tasks.
When a Context being disposed, all FinalizationGroups that are
associated with it are removed from the dirty list, cancelling
scheduled cleanup.
Bug: v8:8179
Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66184}
We lower each op into num_lanes loads, and connecting up the effects in
a chain.
s64x2 is not implemented since we lowering for 64x2 generally doesn't
work anyway.
Load extends are a bit more complicated, so we'll do that in a separate
change.
Bug: v8:9886
Change-Id: I80096827bf8e8e0db1ef0ad1b76759ed1797ca5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031893
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66183}
This change moves the definition of the bits stored in DebugInfo::flags
to Torque, and updates the only Torque usage of that field to use more
natural syntax. This is intended as an example of common patterns found
in various other classes. Several supporting changes are required:
1. Add a new type representing a bitfield struct stored within a Smi. It
is currently called SmiTagged, but I'm open to suggestions.
2. Add an enum-style output for Torque bitfield structs whose bitfields
occupy only one bit each.
3. Add a new case to MachineOperatorReducer that makes the generated
code for IncBlockCounter match with what was generated before this
change.
4. Add support for reporting these bitfields in the postmortem debugging
API. The format matches existing bitfields but with an offset value
that includes the SMI shift size.
Bug: v8:7793
Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66182}
These were not added in https://crrev.com/c/2026067 when we added
similar tests for other lane sizes, since x64 had a completely different
path for i8x16. But this tests are useful anyway for other archs, so add
them in.
Bug: v8:10115
Change-Id: I77ecca0cd9f4021c94f1538aa5635b5d54983207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041708
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66178}
GlobalSize will be used as a hint to schedule scavenger work in
https://chromium-review.googlesource.com/c/v8/v8/+/2036661
This is implemented as an atomic variable that's updated when adding/removing
segments.
Bug: chromium:1012816
Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66175}
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB
if the physical memory size is greater or equal to 16GB on 64-bit
platforms.
This CL also adds tests for configuring heap limits from the physical
memory size.
Bug: chromium:1045034
Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66174}
We used to optimize functions that are expected to executed only
once by not allocating feedback slots for some of the bytecodes. This
would help in reducing the memory and avoiding initializing feedback
that would be never used. With lazy feedback allocation, we don't
allocate feedback vectors for most of such functions anyway.
The generated bytecode for oneshot optimized functions is different and
if we don't properly track this information we might end up generating
different bytecode for the same function. This could causes problems
when there is a mismatch between the feedback slots used by the new
bytecode and the old bytecode. Since we potentially get most of the
benefits of this optimization with lazy feedback vector allocation
we can simplify the code by disabling this optimization.
Bug: chromium:1045824
Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66172}
Allow caching the result of allocating AstConsStrings, to allow
sharing of inferred names between functions.
This is a partial revert of https://crrev.com/c/2020953, with
the observation that *some* AstConsStrings are always flattened,
while others are only ever used as ConsStrings, so we want to
allow the allocation to be lazy while still caching the result.
As a drive-by, cleanup the old AstConsString linked list fields.
Bug: chromium:1011762
Bug: chromium:1048082
Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66168}
This is a reland of 410ca4c50e
Skip new test for unsupported liftoff architecture.
Previously, if there is some unsupported liftoff functions, it fall
through Turbofan but recompilation didn't catch and count it. This CL
fixes it by using requested_tier on finished units.
Avoid to tier down asm.js.
Introduce reached recompilation tier to monitor recompilation progress.
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=szuend@chromium.org,bmeurer@chromium.org
Bug: v8:9654
Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66164}
With "Value::parseBinary" now being revamped by https://crrev.com/c/2020518
and making use of "cbor::ParseCBOR", the extra endianness check
is not needed anymore as "ParseCBOR" already switches
the byte order in this line:
crdtp/cbor.cc
void ParseUTF16String(CBORTokenizer* tokenizer, ParserHandler* out) {
....
for (size_t ii = 0; ii < rep.size(); ii += 2)
value.push_back((rep[ii + 1] << 8) | rep[ii]);
...
"String16EndianTest" does not go through the newly added pipeline
and "ParseUTF16String" is never used which makes the test redundant.
Change-Id: I6ad59fef7036c70d475b492407fd394977ca98f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038716
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66160}
A pointer-compressed heap has the same heap limit heuristics as a 32-bit
heap. Specifically, the heap limit is restricted to 1GB due to scarce
virtual addresses space on 32-bit platforms. That limitation does not
apply for pointer-compressed heaps which can use 4GB.
This CL changes the heap limit computation to use system the pointer
size instead of the tagged pointer size. Note that the young generation
limit continues to use the tagged pointer size.
Bug: chromium:1045034
Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66159}
Add off-thread support for literals, including object/array boilerplates.
Notably, this includes adding FixedArray and HeapNumber support to
OffThreadFactory.
As a drive-by, OffThreadHandle is redefined to store an Address rather
than an Object, similar to Handle, so that it still works with forward
definitions of types.
Bug: chromium:1011762
Change-Id: I7c8452f450d8c57fe683a9e44532ce5647c84a11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036084
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66156}
The source position is set to the function call (console.log) not the
spread (..x), in the bytecode generator, as the spread operation is
done as part of the CallWithSpread bytecode.
The CallPrinter stops at the function call and doesn't look at the
arguments as well (in CallPrinter::VisitCall) to see if the error is
from an incorrect spread operation.
With this patch, we pass some state to the CallPrinter in the
CallWithSpread error case and check that in CallPrinter::VisitCall
before returning.
For the given source string:
```
x = undefined;
console.log(1, ...x);
```
Previously, the error was -
```
test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
console.log(1, ...x);
^
TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
at test.js:2:9
```
Now, the error is -
```
_test.js:2: TypeError: x is not iterable (cannot read property undefined)
console.log(1, ...x);
^
TypeError: x is not iterable (cannot read property undefined)
at _test.js:2:9
```
Bug: v8:10038
Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66131}
If new Liftoff code is generated but we already have either Liftoff or
TurboFan code, we still want to install and use the new Liftoff code if
we are in debugging.
This logic can probably be simplified again when the "tier down to
liftoff on Debugger.enable" logic is fully implemented. I left a TODO to
revisit the logic later.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66129}
These instructions were probably leftover from an earlier cleanup. We
can move them into respective macro lists, then delete away the
redundant declarations, definitions, disasm, and tests.
We were missing disasm tests for SSE2_INSTRUCTION_LIST_SD, so add that
in.
Change-Id: I8f27beaf57e7a338097690073910a0863f00b26a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036833
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66123}
The instruction selector assumed for Word32AtomicPairCompareExchange
nodes that if there exists a Projection(1) user, then there also exists
a Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66122}
This relands commit 5cfe053e45.
Original change's description:
> [wasm-simd][liftoff] Add S128 case for stack movements
>
> The two cases we are fixing here are Construct and
> LoadCallerFrameSlot, which are closely related.
>
> Construct is called during PrepareCall, where we build up
> LiftoffStackSlots when we need to move an arg from caller's stack frame
> into callee's stack frame. LoadCallerFrameSlot is the parallel to
> this, called in ProcessParameter during decoding of the callee's
> function body.
>
> In most cases, Construct needs a new case to handle kWasmS128, and calls
> the relevant assembler to push a s128 onto the stack.
>
> ARM64 requires 16-byte alignment of sp, so we need to Claim the right
> number of kXRegSize slots first, which requires
> us traversing the list of slots to figure out how many s128 values there
> are. This is a straightforward way to fix this, if efficiency is a
> problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
>
> On IA32, pushing s128 values will require 4 calls to push. Instead, we
> use a sub and two movdqu, which will generate less code in most cases.
>
> On x64, there is no 128-bit push, so we call push twice.
>
> Bug: v8:9909
> Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65956}
Bug: v8:9909
Change-Id: Icdaead289abe13faf75bb9e049929f7fd7c59a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036760
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66119}
The debug side table is indexed by pc offset. Offsets change if
breakpoints are added or removed, hence we cannot reuse the debug side
table when compiling another version of the function (with a different
set of breakpoints). Thus store the debug side table per code object
instead of per function.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ifd77dd8f43c9b80bc4715ffe5ca8f0adca2aaf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030922
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66110}
This is mostly used for regression tests which don't need that function.
If we want to wrap it for inclusion in an existing test file, we can
easily add a function around it, and name it properly.
R=ahaas@chromium.org
Bug: v8:10177
Change-Id: I2aedcdfad09fe1fe07af9f0caa2b8bd45da902f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66102}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
This changes how we setup modules from being entirely bytecode based to a
single fixed array with metadata that's passed into a runtime function
DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
replace the bytecode that calls those functions with explicit calls before we
even start running the code. In the case of modules that will obviate the need
for modules to be generators.
Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66097}
If we need a byte register, but {src} is none, we should definitely use
another register.
R=ahaas@chromium.org
Bug: chromium:1048241
Fixed: chromium:1048241
Change-Id: I3396826986e1823250ad6855b84f4b05faaf3b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036073
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66095}
When the embedder integrates in V8's garbage collector the performance
of the atomic phase is sensitive to how much embedder memory is found
through marking the overall transitive closure.
Before this patch, V8 would help out tracing the embedder's heap when
making progress through tasks but not on allocations. In addition, V8
would complete the garbage collection when it has observed it's own
marking worklists as empty 3 times (*). This can create performance
cliffs when there's a lot of work still to be done on the embedder
side.
This patch adds helping steps on allocation that are proportional to
the bytes that V8 would otherwise process, guaranteeing some progress
as long as there's V8 allocations. This allows us to remove (*).
Potential Tradeoffs:
- More time spent in V8's garbage collection metrics as we slightly
limit the chances for the embedder to mark objects through tasks.
- Prolonged V8.execute time (JS execution)
+ Faster progress
+ Less memory
+ Smaller atomic pause time
Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
Bug: chromium:1044630
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66091}
This relands commit 7c32fa05df.
Some test cases need to be updated, since we will bail out to TurboFan
where previously Liftoff was happy to run, when SIMD is not supported.
Original change's description:
> [wasm-simd][liftoff] Check CpuFeatures for SIMD support
>
> If Wasm simd128 is not supported on this particular hardware, we bail
> out to TurboFan.
>
> Bug: v8:9909
> Change-Id: Ie46e154426783ba099b7c0facc906670cda1bdd0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029427
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66055}
Bug: v8:9909
Bug: v8:10169
Change-Id: I850e1fe6bfbd12fb2eec052aa8367624c09f7a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030354
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66090}
After allowing larger strings on 64-bit builds, this test OOMs on
Android devices that don't have enough memory.
Tbr: machenbach@chromium.org
Change-Id: I05c44d7074388a4306e5266ba1aa9da760c83377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035877
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66089}
The assembly of sqrtpd when using Sqrtpd macro was wrong, since
Sqrtpd(xmm1, xmm1) will incorrect generated vsqrtpd(xmm1, xmm1, xmm1),
which is nonsensical, since vsqrtpd only takes two operands. The
expected instruction should be vsqrtpd(xmm1, xmm0, xmm1) in terms of the
encoding, which is vsqrtpd(xmm1, xmm1).
So, move sqrtpd and cvtps2dq out into their own macro list, because
they have two operands in their AVX form, unlike the rest of the
instructions in SSE2_INSTRUCTION_LIST.
Also updated disasm and tests to use this new list.
Fixed: v8:10170
Change-Id: Ia9343c9a3ae64596bbc876744556e1dcea2a443b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032195
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66088}
This CL implements functionality to allow an embedder to mark a
debug scope as terminate-on-resume. This results in a termination
exception when that debug scope is left and execution is resumed.
Execution of JavaScript remains possible after a debug scope is
marked as terminate-on-resume (but before execution of the paused
code resumes).
This is used by blink to correctly prevent resuming JavaScript
execution upon reload while being paused at a breakpoint.
This is important for handling reloads while paused at a breakpoint
in blink. The resume command terminates blink's nested message loop
that is used while to keep the frame responsive while the debugger
is paused. But if a reload is triggered while execution is paused
on a breakpoint, but before execution is actually resumed from the
breakpoint (that means before returning into the V8 JavaScript
frames that are paused on the stack below the C++ frames that belong
to the nested message loop), we re-enter V8 to do tear-down actions
of the old frame. In this case Runtime.terminateExecution() cannot be
used before Debugger.resume(), because the tear-down actions that
re-enter V8 would trigger the termination exception and crash the
browser (because the browser expected the tear-down to succeed).
Hence we introduce this flag on V8 that says: It is OK if someone
re-enters V8 (to execute JS), but upon resuming from the breakpoint
(i.e. returning to the paused frames that are on the stack below),
generate a termination exception.
We deliberated adding a corresponding logic on the blink side (instead
of V8) but we think this is the simplest solution.
More details in the design doc:
https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
Bug: chromium:1004038, chromium:1014415
Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
This is a reland of 9781aa076f
Original change's description:
> Reland "[wasm] Cache streaming compilation result"
>
> This is a reland of 015f379aa1
>
> Original change's description:
> > [wasm] Cache streaming compilation result
> >
> > Before compiling the code section, check whether the
> > bytes received so far match a cached module. If they do, delay
> > compilation until we receive the full bytes, since we are likely to find
> > a cache entry for them.
> >
> > R=clemensb@chromium.org
> >
> > Bug: v8:6847
> > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66000}
>
> Bug: v8:6847
> Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66047}
Bug: v8:6847
Change-Id: I272f56eee28010f34cc99df475164581c8b63036
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66081}
Define a macro in code-generator-x64 to help identify cases when the
shift value is an immediate/constant. In those cases we can directly
emit the shifts without any masking, since the instruction selector
would have modulo-ed the shift value. We also don't need any temporaries
in this case.
This is only x64 codegen, optimizations for other archs will come in
future patches (and will probably look very similar to this).
The current test case passes the shifts as an immediate, so we add a new
path that loads the shift value from memory, thereby exercising the
slower path of non-immediate shift value.
Bug: v8:10115
Change-Id: Iaf13d81595714882a8f5418734e031b8bc654af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026067
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66074}
This relands commit e8832647b6.
The flaky test failures seems to be related to tiering, Liftoff
generating different call descriptors from TurboFan when Simd128
is unsupported (since TurboFan will lower the graph, but Liftoff
can continue running simd-call.js just fine).
We temporarily disable tiering for this test, until we get a proper fix,
like https://crrev.com/c/2029427/, but that fix requires this change
since more tests will fail without the lowering fixed.
Bug: v8:10169
Bug: v8:10154
Original change's description:
> [wasm-simd] Fix scalar lowering of kParameter
>
> Lowers the call descriptor of a wasm function if it contains simd.
>
> Also fixes a couple of issues with the lowering of kParameter:
> - the old_index == new_index check is incorrect, it would only work if
> the s128 parameter is the first parameter
> - the old_index was also not adjusted to account for Parameter[0] being
> the wasm instance object
> - new_index needs to be adjusted to account for the instance object too
>
> These fixes make it more similar to the lowering of kParameter in
> int64-lowering.c.
>
> Also add a new mjsunit test to exercise this logic.
>
> Bug: v8:10154
> Change-Id: Ia767a464c26a6a78fd931eab9e6897890a0904e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020521
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66032}
Change-Id: I1e27825025aefc5a42aeeb87d0447d6594388fa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029147
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66072}
We will use this state in devtools via the inspector to indicate
whether a thread is currently stuck polling in atomics.wait.
VMState already distinguishes the important states we care about which
are idle vs. running JS. We also want to know the state for
atomics.wait(), which is commonly used in WebWorkers to poll the main
page for work to do.
This CL just adds and maintains the state and adds assertions in
atomics tests. Another CL will emit inspector notifications when the
VMState changes in a way that the inspector cares about.
Re-flow comments as a drive-by cleanup.
Bug: chromium:1025490
Change-Id: I961051bfb846aa20454a56214310370ea8e47d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033168
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66071}
The flag is unused.
Bug: chromium:1044630
Change-Id: Ib499cdd559451c9f23c3c98b187755ef6748bffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030743
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66070}
This adds two flags for whitelisting natives on fuzzers:
--allow-natives-for-fuzzing:
Enables a small subset of runtime functions and replaces others with
undefined.
--allow-natives-for-differential-fuzzing
Restricts the allowed runtime functions even further, excluding the
ones that break differential fuzzing.
Bug: chromium:1044942
Change-Id: I890bd4a6ff7c2e483dd74155290a7ace06f85239
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020773
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66068}
Factory::NewFunction now requires names passed into it to be flat.
Make sure to flatten Wasm function names when creating new Wasm JS
functions.
Fixes: chromium:1047368
Change-Id: I7bd2d8bc83ae8fab901ab469872bce0f703fc3ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030738
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66064}
This shipped in v7.9, which is stable since six weeks. We do not test
the previous configuration any more and don't plan to move back, hence
remove the flag and clean up the code.
R=ahaas@chromium.org
Bug: v8:10155
Change-Id: I6b981f4be686473a911f041952cb684749d9fe7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030732
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66063}
As discussed offline, the current implementation implement each
situation separately. I think we can simplify the code a lot by sharing
code between the different paths.
This CL does that by
1) implementing the kI64Store case separately, because it does not have
all the register contraints that the others have, and
2) moving all logic to ensure that the {src} register is usable before
the switch, such that it's shared by all the compare-exchange cases.
As a side produce, this also fixes issue 1045225, because for i64 stores
which actually only use the lower half of {src}, only that half will be
pinned.
R=ahaas@chromium.org
Bug: chromium:1045225, v8:10108
Change-Id: I0be025b9706d563835ae6337d45b88e0233eacad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029414
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66062}
On backends that do not have s128 support in Liftoff, tests will bail
out to TurboFan, so tests will continue running and passing.
Bug: v8:9909
Change-Id: I3b596a73b6cb2e8645a99c65a935026f9e1a8d55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029332
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66056}
This reverts commit 410ca4c50e.
Reason for revert: This was causing Chrome to hang when debugging large wasm binaries.
Clean revert except for modification to test/debugger/debugger.status
Bug: chromium:1047210, v8:9654
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=clemensb@chromium.org,bmeurer@chromium.org,duongn@microsoft.com,szuend@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9654
Change-Id: Id49e8c69f8212e95e698d7e7267056fb2eb7e60a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030737
Auto-Submit: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66054}
There was a bug in the function body decoder where
type checking of brtable only happened if the brtable
instruction is reachable. However, type checking is
required in all cases where brtable "not unreachable".
The difference between reachable and "not unreachable"
is a state called spec-reachable where a clever
compiler can already infer that the code will be
unreachable (e.g. a memory access is out of bounds
just by the offset and therefore unconditionally
traps), but the spec can not. If an instruction is
only spec-reachable, it still has to be type checked.
R=clemensb@chromium.org
FIX=chromium:1046472
Change-Id: I7e9f1108597871615c0d443a0e94de35a0207b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66049}
This is a reland of 015f379aa1
Original change's description:
> [wasm] Cache streaming compilation result
>
> Before compiling the code section, check whether the
> bytes received so far match a cached module. If they do, delay
> compilation until we receive the full bytes, since we are likely to find
> a cache entry for them.
>
> R=clemensb@chromium.org
>
> Bug: v8:6847
> Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66000}
Bug: v8:6847
Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66047}
This patch adds a new BackingStore::Reallocate function that internally
uses a new ArrayBuffer::Allocator::Reallocate provided by the embedder.
The default implementation of the function simply copies the backing
store. The embedder can override the function and provide a more
efficient implementation e.g. using realloc.
Bug: v8:9908, v8:9380
Change-Id: I2179c80ba199c045b6900c620a813916150e7098
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007274
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66044}
... by using random seed provided via --gtest_random_seed= flag.
Bug: chromium:1043117
Change-Id: I6114e9c71f3196a386a8457a6ec6f9e1fc80f6ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027991
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66043}
Remove AstConsString "internalization", and instead make the conversion
to heap String be on-demand with an Allocate method. We never actually
need the heapified cons string more than once, so there's no need to do
the internalization walk or do the next/string union dance in the
AstConsString class.
This also allows us to specify how we want to allocate the String at the
call site. In particular, it allows us to allocate a flat SeqString rather
rather than a ConsString. This allows us to avoid allocating ConsStrings
which will just be passed to a flatten call, and especially avoid
allocating dead ConsStrings in the off-thread old space.
Bug: chromium:1011762
Bug: chromium:1043168
Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66042}
When the file begins with a hashbang, the scanner is in a failed state
when SkipHashbang() is called. This is usually not an issue but when
the parser encounters an ILLEGAL token, it will reset the SyntaxError
location because of it.
Bug: v8:10110
Change-Id: I1c7344bf5ad20079cff80130c991f3bff4d7e9a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995312
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66038}
This reverts commit e8832647b6.
Reason for revert: Causes flaky fails on the tree, reverting as this test should be deterministic pass/fail.
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8889903130443940000/+/steps/Check_-_nosse3__flakes_/0/logs/simd-call/0
Original change's description:
> [wasm-simd] Fix scalar lowering of kParameter
>
> Lowers the call descriptor of a wasm function if it contains simd.
>
> Also fixes a couple of issues with the lowering of kParameter:
> - the old_index == new_index check is incorrect, it would only work if
> the s128 parameter is the first parameter
> - the old_index was also not adjusted to account for Parameter[0] being
> the wasm instance object
> - new_index needs to be adjusted to account for the instance object too
>
> These fixes make it more similar to the lowering of kParameter in
> int64-lowering.c.
>
> Also add a new mjsunit test to exercise this logic.
>
> Bug: v8:10154
> Change-Id: Ia767a464c26a6a78fd931eab9e6897890a0904e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020521
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66032}
TBR=gdeepti@chromium.org,ahaas@chromium.org,zhin@chromium.org
Change-Id: I69589e2331c857c0f197ac53b8fb8a241376c632
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028830
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66034}
Lowers the call descriptor of a wasm function if it contains simd.
Also fixes a couple of issues with the lowering of kParameter:
- the old_index == new_index check is incorrect, it would only work if
the s128 parameter is the first parameter
- the old_index was also not adjusted to account for Parameter[0] being
the wasm instance object
- new_index needs to be adjusted to account for the instance object too
These fixes make it more similar to the lowering of kParameter in
int64-lowering.c.
Also add a new mjsunit test to exercise this logic.
Bug: v8:10154
Change-Id: Ia767a464c26a6a78fd931eab9e6897890a0904e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020521
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66032}
Tests need to be disable until liftoff is fully implemented.
Change-Id: Ib906b7d4ef2abae1359fbfb1a61031eeb5d5e70c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028289
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66028}
Copying one object's named properties is always fine, even if one of
the names could be a large index on a TypedArray. Mark the LookupIterator
as OWN_SKIP_INTERCEPTOR to avoid the DCHECK.
Bug: chromium:1044909
Change-Id: I6918186a4b50df7865de3572cb674fd7d6eadb78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023558
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66027}
... which didn't check writability of array length on appending
a new element to an array.
Bug: chromium:1041251
Change-Id: I6935e505a4844e5b22abe9d4a42786619499daa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023551
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66023}
This reverts commit 7d1f95d6e4.
Reason for revert: Speculative revert for https://crbug.com/1046678
Original change's description:
> [regexp] Correctly escape a backslash-newline sequence
>
> When printing the source string, a backslash-newline sequence ('\\\n',
> '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
> '\u2028', '\u2029', respectively. Prior to this CL it was formatted as
> a backslash followed by the literal newline character.
>
> Bug: v8:8615
> Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65986}
TBR=neis@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8615,chromium:1046678
Change-Id: If28626a1c6868ed848310c0d30cf61a73326f2c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027452
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66022}
The compiler assumes (for loads) that the property cell of a
non-configurable global property never gets invalidated.
Bug: chromium:1044919
Change-Id: I27f6ce30fb9a21e2c1e5310f25e9bb973ebbc266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023562
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66021}
Converting an object to an array length can freeze the array whose
length is being set, but SetLength for the frozen elements accessor
is supposedly unreachable. This fix extends the existing special
handling for suddenly-readonly lengths to cover this case as well.
Prior art: https://codereview.chromium.org/2543553002
Bug: chromium:1044911
Change-Id: I85d2e79446a8d9c1d22cd86ddf828328bf51a1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023555
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66020}
Put a logic in Wasm Engine to tier down all existing modules per isolate
when debugger is enabled. This CL does not handle new module added after
debugger is enabled yet.
Bug: v8:9654
Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66017}
These conversion instructions were removed from the proposal in
https://github.com/WebAssembly/simd/pull/178.
Change-Id: I212ca2f923362bf08e178f6d28cc2338cf6f5927
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016006
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66015}
This CL fixes a parser crash in REPL mode. Some SyntaxErrors can cause
the AST to contain NULL nodes, resulting in a crash when we want to
rewrite the AST after parsing.
Instead of re-writing a broken AST we bail early.
R=leszeks@chromium.org
Bug: chromium:1040034, chromium:1045758
Change-Id: I9c559f6de5969c8db17833ccbdb1608627b46311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023547
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66008}
The current implementation takes forwarding reference arguments, which
is fine when you call it with rvalues, like
make_iterator_range(V.begin(), V.end()). If you call it with lvalues
though, it doesn't do what you'd expect. ForwardIterator becomes a
reference:
Foo I = V.begin();
make_iterator_range(I, I); //ForwardIterator is deduced as Foo&
Since iterator are supposed to be small, no harm in passing them by
value.
Change-Id: I151c87304949d810c72c42f60e9d1a7151f61f83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020780
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66007}
This reverts commit 015f379aa1.
Reason for revert: Msan is unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/30702
Original change's description:
> [wasm] Cache streaming compilation result
>
> Before compiling the code section, check whether the
> bytes received so far match a cached module. If they do, delay
> compilation until we receive the full bytes, since we are likely to find
> a cache entry for them.
>
> R=clemensb@chromium.org
>
> Bug: v8:6847
> Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66000}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Idfa5b3f354816eb600ae7aab7857063d5d0d27ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6847
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022949
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66001}
Before compiling the code section, check whether the
bytes received so far match a cached module. If they do, delay
compilation until we receive the full bytes, since we are likely to find
a cache entry for them.
R=clemensb@chromium.org
Bug: v8:6847
Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66000}
Fix the string representation of functions exported from asm.js modules
in the presence of imported functions.
R=jkummerow@chromium.org
Bug: chromium:1045767, chromium:667678
Change-Id: I55714252036511598eeec7fe7b81985213f7e4f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022142
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65993}
Add a test that does the same thing the devtools-frontend does when
evaluating console inputs.
1) Declare a const variable with throwOnSideEffect=true. This should
throw.
2) Declare the same const variable with throwOnSideEffect=false.
This should successfully declare the variable.
Previously it could be the case that even though we threw in 1), the
variable would fail to be initialized in 2) with a re-declaration
error.
Bug: chromium:1043151
Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65991}
This CL introduces the negb and negw instructions (8-bit and 16-bit
versions of neg) in the x64 assembler. These instructions are needed to
implement I32AtomicSub8U and similar WebAssembly instructions
efficiently.
The existing implementation was embedded in a generic macro, and it was
difficult to change it without introducing also the 8-bit and 16-bit
versions of many other instructions. This would have introduced a lot
of dead code. Instead this CL extracted the neg instructions from the
macro and implements them directly. This should be fine because the
assembler does not change much, and approachability of the code is
improved.
R=clemensb@chromium.org
Bug: v8:10108
Change-Id: I46099bbebd47f864311a67da3ba8ddc4fe4cd35d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019165
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65989}
When printing the source string, a backslash-newline sequence ('\\\n',
'\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
'\u2028', '\u2029', respectively. Prior to this CL it was formatted as
a backslash followed by the literal newline character.
Bug: v8:8615
Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65986}
When ArrayBufferExtensions are enabled, sweep the extensions outside of
the GC pause concurrently to the application. The following GC will make
sure that the previous concurrent sweep operation is finished.
This CL introduces Heap::array_buffer_sweeper() that is both
responsible for tracking all extensions but also for sweeping.
Bug: v8:10064
Change-Id: I113cd625445a7d59ffb7a9de8b25a15a72b02b99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010107
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65984}
Remove the execution tier check for simd tests. On archs without
Liftoff, those tests that are configured to run on Liftoff will fail
with this check, since they bail out to TF.
We remove this check for now, but will think of a way to enforce this in
a more platform specific way.
Bug: v8:9909
Change-Id: Id56f841fe6e342434af3dbcdaef0a8a284614994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019924
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65983}
We currently print asm.js functions converted to wasm as
"function foo() { [native code] }", even though without asm to wasm
translation we get the proper source code. This is an observable
difference that should not be, and also foozzie finds this frequently in
different variations.
This CL makes us remember the start position (position of the "function"
token) and end position (right behind the closing "}") of each function
we transform to wasm. These offsets, together with the Script that
contained the function, allows us to reconstruct the source code of the
function for the {toString()} method.
R=jkummerow@chromium.org
Bug: chromium:667678
Change-Id: If22471cad4cefdfc67f6d1b8fda85aa0eeb411bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016582
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65972}
This relands commit 009993adb4.
The fix is in liftoff-assembler-ia32.h, the codegen was incorrect.
Original change's description:
> Implement f32x4.splat and enable handling this in Liftoff.
>
> We add a new macro for defining test cases to run on TurboFan, Liftoff,
> interpreter, and scalar lowering.
>
> Also add an assertion that the execution tier used is what we expected
> it to be. This is useful for Liftoff, because by default it falls back
> to TurboFan when it encounters an unimplemented opcode.
>
> Bug: v8:9909
Bug: v8:9909
Change-Id: I7daacbe8b195d9212367190c515b0babbc457a88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018043
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65963}
This change adds support for the postmortem inspection library to show
the content of cached external strings if that content is available. It
also fixes a minor annoyance where strings with unavailable data would
show up as "...". Now, if fetching the very first character fails, we
omit the literal value from the output.
Bug: v8:9376
Change-Id: Id694a774c231ab3467fb59b1c149284729acfb20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987922
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65961}
This reverts commit 5cfe053e45.
Reason for revert: "liftoff-simd-params" also fails on no-sse :/
Original change's description:
> [wasm-simd][liftoff] Add S128 case for stack movements
>
> The two cases we are fixing here are Construct and
> LoadCallerFrameSlot, which are closely related.
>
> Construct is called during PrepareCall, where we build up
> LiftoffStackSlots when we need to move an arg from caller's stack frame
> into callee's stack frame. LoadCallerFrameSlot is the parallel to
> this, called in ProcessParameter during decoding of the callee's
> function body.
>
> In most cases, Construct needs a new case to handle kWasmS128, and calls
> the relevant assembler to push a s128 onto the stack.
>
> ARM64 requires 16-byte alignment of sp, so we need to Claim the right
> number of kXRegSize slots first, which requires
> us traversing the list of slots to figure out how many s128 values there
> are. This is a straightforward way to fix this, if efficiency is a
> problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
>
> On IA32, pushing s128 values will require 4 calls to push. Instead, we
> use a sub and two movdqu, which will generate less code in most cases.
>
> On x64, there is no 128-bit push, so we call push twice.
>
> Bug: v8:9909
> Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65956}
TBR=clemensb@chromium.org,zhin@chromium.org,joey.gouly@arm.com
Change-Id: Ib3c5a088e2d85baf1d8b143272844fb5ebb33c57
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017724
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65960}
This reverts commit 009993adb4.
Reason for revert: New test fails, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/35534 and https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/23778
Original change's description:
> [liftoff][wasm-simd] Implement f32x4.splat
>
> Implement f32x4.splat and enable handling this in Liftoff.
>
> We add a new macro for defining test cases to run on TurboFan, Liftoff,
> interpreter, and scalar lowering.
>
> Also add an assertion that the execution tier used is what we expected
> it to be. This is useful for Liftoff, because by default it falls back
> to TurboFan when it encounters an unimplemented opcode.
>
> Bug: v8:9909
> Change-Id: I594955fce778173191fc44c38c4f956a05e77839
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2014753
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65954}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: Ie6970a8c29baab149150dd734a95f89be5fd89ff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2017722
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65958}
The following instructions are affected: memory.init, data.drop,
table.init, table.drop. A segment index should be decoded as an unsigned
number, but these instructions were decoding as signed. This works
properly up to 63, but fails at 64 (which is decoded as -64 =
4294967232).
Bug: v8:10151
Change-Id: I742b74cf0bcadf2ff2f606beb65b7bae3e816530
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015960
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65957}
The two cases we are fixing here are Construct and
LoadCallerFrameSlot, which are closely related.
Construct is called during PrepareCall, where we build up
LiftoffStackSlots when we need to move an arg from caller's stack frame
into callee's stack frame. LoadCallerFrameSlot is the parallel to
this, called in ProcessParameter during decoding of the callee's
function body.
In most cases, Construct needs a new case to handle kWasmS128, and calls
the relevant assembler to push a s128 onto the stack.
ARM64 requires 16-byte alignment of sp, so we need to Claim the right
number of kXRegSize slots first, which requires
us traversing the list of slots to figure out how many s128 values there
are. This is a straightforward way to fix this, if efficiency is a
problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
On IA32, pushing s128 values will require 4 calls to push. Instead, we
use a sub and two movdqu, which will generate less code in most cases.
On x64, there is no 128-bit push, so we call push twice.
Bug: v8:9909
Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65956}
Implement f32x4.splat and enable handling this in Liftoff.
We add a new macro for defining test cases to run on TurboFan, Liftoff,
interpreter, and scalar lowering.
Also add an assertion that the execution tier used is what we expected
it to be. This is useful for Liftoff, because by default it falls back
to TurboFan when it encounters an unimplemented opcode.
Bug: v8:9909
Change-Id: I594955fce778173191fc44c38c4f956a05e77839
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2014753
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65954}
Port 7b79a02d2b
Original Commit Message:
This CL adds a --debug-in-liftoff flag, which takes another path in
{WasmScript::SetBreakPointForFunction}, and sets the breakpoint via
{wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++
interpreter related).
Actual breakpoint support is not there yet, so the new test which sets
this flag does not currently break anywhere. This will change with a
future CL.
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I632e4c945c88f58d8caba8688356f66406bc04aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016915
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65953}
The NativeModule that was serialized in another isolate might be
temporarily kept alive by background threads. By keeping a weak pointer
to the module, we can wait for it to really die.
This happens very rarely, and the module will die pretty quickly, so
busy-waiting is fine in this case.
R=thibaudm@chromium.org
Bug: v8:10148
Change-Id: I8c4645acfccd04a820ef3f694cad3eb15e75acb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016585
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65942}
The instruction selector assumed for Word32AtomicPairBinop nodes that if
there exists a Projection(1) user, then there also exists a
Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: I22331cae58f933e89dac6993fe3b21ff6502838a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011829
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65941}
This CL implements load_extend with 2 lanes and all load_splat
operations on IA32. The necessary assemblers together with their
corresponding disassemblers and tests are also added in this CL.
The newly added opcodes include: S8x16LoadSplat, S16x8LoadSplat,
S32x4LoadSplat, S64x2LoadSplat, I64x2Load32x2S, I64x2Load32x2U.
Bug: v8:9886
Change-Id: I0a5dae0a683985c14c433ba9d85acbd1cee6705f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1982989
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
Cr-Commit-Position: refs/heads/master@{#65937}
This flag was used for IndexedDB support. Last uses in chrome were
removed in https://crrev.com/c/2013046, hence the API method can be
deprecated.
Also remove deserializer tests that were disabled by default or just
test that random bytes (from the deserializer's perspective) fail
to decode.
R=adamk@chromium.org
Bug: v8:10146
Change-Id: I8596849c3b51ab1c60272a49ff3fdaa0946452bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013104
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65931}
Both the API wrapper as well as the internal object are named
"WasmModuleObject". This CL renames the object type check from
"IsWebAssemblyCompiledModule" to "IsWasmModuleObject" to be consistent.
R=adamk@chromium.org
Bug: v8:10021
Change-Id: I6d5814421f38bc5f5bd73a492ff4a36f552ff763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013109
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65930}
This is a reland of faccc95b77
Since 1c9bb77de5, async jobs use existing
entry in native module cache and skip recompilation so we need to fix
the test.
Original change's description:
> Reland "[wasm] Perform NativeModule tier down in parallel."
>
> This is a reland of 3352fcc900
>
> Disable stress-opt for test and check recompilation before clearing
> callbacks.
>
> Original change's description:
> > [wasm] Perform NativeModule tier down in parallel.
> >
> > Reuse logic in {CompileNativeModule} function in module-compiler.cc:
> > initialize parallel compile jobs, then wait for them to finish while
> > taking part in this compilation.
> >
> > Bug: v8:9654
> > Change-Id: I9974d9f8b516e9faec716a592c7c0ee9c7077d8e
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977041
> > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#65763}
>
> Bug: v8:9654
> Change-Id: I8e8830f05e189596207365b7332a2cc25e493e47
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002945
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65901}
Bug: v8:9654
Change-Id: Ia63b86d4275088d93202046bc9823e6202b7991a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2012986
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65929}
The actual allocatable size still depends on the allocator;
in particular Blink's ArrayBufferAllocator is currently limited
to 2GB.
WebAssembly memories are not affected by this change (i.e. still
capped at 2GB as well).
For 32-bit platforms, the limit remains at 2**30-1 (=max smi) elements.
Bug: v8:4153
Change-Id: If0d6047dd4061028688d85a3dc0a2684dcca8693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007495
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65924}
Serialization of WasmModuleObject was our first implementation for
postMessage, and was used for IndexedDB. IndexedDB support is removed
since a long time, and postMessage works by just messaging an identifier
and reusing the underlying NativeModule when receiving this.
Thus the logic to serialize the actual code is unused, and thus should
be removed together with all tests.
R=ahaas@chromium.org
Bug: v8:10146
Change-Id: I599296736dabd486c45ced2b6e5996e490fa40c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013110
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65922}
This CL adds a --debug-in-liftoff flag, which takes another path in
{WasmScript::SetBreakPointForFunction}, and sets the breakpoint via
{wasm::DebugInfo} (Liftoff-related) instead of {WasmDebugInfo} (C++
interpreter related).
Actual breakpoint support is not there yet, so the new test which sets
this flag does not currently break anywhere. This will change with a
future CL.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: I95a905e666b8f502366d2c7273c8f25a267ee184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2012920
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65921}
Changing script context handling from bytecode based to metadata on the
function. This fixes the debugger to explicitly check the code rather
than implicitly relying on a NewScriptContext bytecode causing side
effects.
Bug: chromium:1043151
Tbr: ulan@chromium.org
Change-Id: I38c5c04d7c76155e0a055ae6efd57f25986bdb7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013117
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65920}
This is a reland of 3b7535636f
Original change's description:
> Reland "[runtime] Cache prototype chain enumerable keys in PrototypeInfo"
>
> This is a reland of 5253d7bf15
>
> Original change's description:
> > [runtime] Cache prototype chain enumerable keys in PrototypeInfo
> >
> > This CL adds a prototype_chain_enum_cache to cache the enumeration of a
> > prototype and its entire chain on the PrototypeInfo. It can improve for-in
> > performance via simply merging the receiver enumeration with this cache.
> >
> > It improves the score of JetStream2-tagcloud-SP case by ~9% on IA Chromebook.
> >
> > Contributed by tao.pan@intel.com
> >
> > Change-Id: Ib40bfe41e772672337155584672f06fa1ba1e70d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870844
> > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#65224}
>
> Change-Id: I93b74727c46abbaab163324c50fbd977fcc9bb36
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955232
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Cr-Commit-Position: refs/heads/master@{#65377}
Change-Id: If4b4631e1b8a3d2df748b6be8500f838836a3291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2008253
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65919}
