Rmove the deprecated array.len 0xfb17 variant which takes a type
immediate.
This has been superseded by 0xfb19 which does not need the type.
Bug: v8:7748
Change-Id: I7d4620423c786462444512abe40ee006aab99cf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110831
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85225}
After we received feedback about some legitmate use-cases of the
internal [[Scopes]] property, we decided to not go ahead with its
removal.
This CL removes the corresponding experimental flag.
R=kimanh@chromium.org
Bug: chromium:1365858
Change-Id: I6744889b4e2e960695838648e2f4902cbdb75890
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154416
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85214}
The feature shipped with M109 so we'll remove the flag with M111.
R=jarin@chromium.org
Bug: chromium:1363561
Change-Id: Ia9b276f6c56fb3f57c57f5da1abe02dda8dc36e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154418
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85213}
Currently structref is interpreted as dataref by default for backwards
compatibility reasons.
This behavior is now being removed with this change.
Bug: v8:7748
Change-Id: I610fd04187b1bda53c83a82345eae09f23d99731
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111171
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85211}
When disabled, Turbofan is fully excluded from the compilation result.
This is expected to reduce V8's contribution to chromium's binary size
by roughly 20%.
If Turbofan is disabled, Maglev and Webassembly must also be disabled
(since both depend on TF).
Note this new configuration (v8_enable_turbofan=false) is not yet
used anywhere - we'll probably enable it for lite_mode bots in an
upcoming CL for test coverage.
Changes in detail:
- Split out all src/compiler files from the main source sets. This
was mostly done already, here we only clean up the few files that
were left.
- Define a new main TF entry point in turbofan.h. `NewCompilationJob`
replaces `Pipeline::NewCompilationJob`.
- When TF is enabled, turbofan-enabled.cc implements the above.
- When disabled, turbofan-disabled stubs out the above with a runtime
FATAL message.
- The build process is modified s.t. mksnapshot always has TF
available since it's needed to generate builtins. When disabled,
TF is removed from other components, in particular it is no longer
included in v8_compiler and transitively in v8_base.
- When disabled, v8_for_testing no longer has v8_initializers
available. These were only needed for test-serialize.cc, which
is now excluded from this build mode.
- When disabled, remove all related cctest/ und unittest/ files from
the build.
Bug: v8:13629
Change-Id: I63ab7632f03d0ee4a787cfc01574b5fdb08fd80b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128529
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85210}
The file `at.js` was missing in the resources list, and did therefore
not get uploaded to the perf bot. This caused an error on the perf bot.
R=machenbach@chromium.orgCC=dmercadier@chromium.org
Bug: v8:12926
Change-Id: I199591444da651854633a37e7164756981b9353f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154414
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85208}
Turbofan optimized array access returned incorrect values in some cases
when a negative index was provided. This CL fixes this by changing the
way those bounds checks are performed in JSNativeContextSpecialization.
Bug: chromium:1320641
Change-Id: Id1f06680ccf7964994d179f7fb44199a0b1245b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147622
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85207}
This CL adds some tests for async generators to ensure that we
correctly report caught/uncaught exceptions.
Most of the cases were fixed by the for-of fix:
https://crrev.com/c/4146420
The remaining broken test cases contain a throw directly
after a `yield`. For each ".next" call we create a new promise
that we need to push on the promise stack before we actually
resume the generator.
R=bmeurer@chromium.org
Fixed: chromium:1270780
Change-Id: I8365d20490451be37cc6973d8d91aeffed7e3511
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146421
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85196}
Currently the shared value barrier manually fast paths instance types
for objects that are always in the shared heap. This CL makes a common
superclass, AlwaysSharedSpaceJSObject, and uses that for the fast path.
Bug: chromium:1402920, v8:12547
Fixed: chromium:1402920
Change-Id: I84421802791a4dc72925341eeb0cfc5949b8938a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134475
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85192}
This is a reland of commit ebd933037e
Original change's description:
> [flags,testrunner] Consider readonly flags for conflict detection
>
> Flag conflict detection 1) bails out on incompatible flag values (e.g.
> --jitless and --turbofan) and 2) handles such bailouts transparently in
> the test runner by marking affected tests as OUTCOMES_FAIL.
>
> This CL adds full support for readonly flags to this system, together
> with required additional annotations in variants.py.
>
> Drive-by: assert proper use of v8_enable_slow_dchecks, and add
> support when dcheck_always_on is set.
> Drive-by: introduce has_maglev build variable detection based on
> v8_enable_maglev and use that for .status file annotations.
> Drive-by: protect against unintended overwrites of build variables
> in statusfile.py.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
> Bug: v8:13629,v8:10577
> Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85130}
Bug: v8:13629,v8:10577
Change-Id: I49ce322c3fda00a1e1e280d99d2d818772533927
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151087
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85172}
- For TypedArrays, we bail out trying to reduce the access.
- For DataView, we check dynamically the DataView object bitfield
and call a builtin on a slow path.
Drive by: fix presubmit lint to allow assertOptimized when
passing --maglev flag.
Bug: v8:7700, v8:13645
Change-Id: I3ce4773466f045ff10c86c41734e00fbb94eb331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146435
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85171}
Only byte displacement was handled for opcode F6F7,
this CL adds 32-bit displacement support.
Change-Id: I40b3140df582cd0dce008dbbb957e615751c2131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4144627
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#85166}
The bytecode generator currently uses the wrong catch prediction in
the desugaring for for-of loops. This leads to unexpected pauses in
DevTools when 'pause on uncaught exceptions' is enabled, e.g. for throwing generators.
Specifically the call to .next of the iterator is unconditionally
marked as 'uncaught' instead of using the surrounding catch
prediction. Similarly, in the desugared "finally" block we call
.return which can also throw.
Note that if both the loop body and the ".return" throws, the
exception from ".return" is caught and only the loop body exception
is re-thrown. We still pause on both throw sites since we can't
detect this case statically.
R=leszeks@chromium.org
Bug: chromium:1270780
Change-Id: I2e642ef3fbfcfc6ad19e92cf611188801ebf2450
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146420
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85164}
Drive-by: fix wrong bound check for TypedArrays / DataView on arm64,
which sometimes resulted in unecessary deopts.
Bug: v8:7700, chromium:1405651
Change-Id: I9afb2008edb22c0cd63044a6700a9f276960c191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146437
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85157}
The caller was rewritten but the ignore scope was left behind.
Bug: v8:12819
Change-Id: I76c297f43587bb5bd74c62cf39e0e979271a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110939
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85146}
This CL handles 2 issues with disposing of external string resources in
the string forwarding table:
1) Resources of unmarked strings during GCs with stack are correctly
disposed (these were previously leaking).
2) Resources of unmarked strings during GCs without stack are disposed
at most once. Previously resources could be disposed multiple times if
the same resource had multiple entries in the string forwarding table.
Bug: v8:12957, chromium:1403564
Change-Id: I809ec1ada1ee813d7277e85ade9aa1e3e95a80f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4136725
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85144}
This CL introduces typed optimizations for Turboshaft, which replaces all operations that produce a constant output (and don't have side effects) by the corresponding constant.
In addition, a new pass for eliminating dead code is introduced that cannot only remove dead operations, but also rewrite branches that are not required into GotoOps.
Drive-by: Introduce -0 as a "special value" for Float32Type and Float64Type to fix a few issues where 0 and -0 have been treated as identical.
Bug: v8:12783
Change-Id: Ia1450ad7a9abb5d58c7d753596ed08a33a73184f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110993
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85143}
EmbedderHeapTracer has been removed, making the separate main-thread
worklist obsolete.
Bug: v8:13207
Change-Id: I3f92457a73d6664b28646247548b78ade491be32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4136716
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85142}
This reverts commit ebd933037e.
Reason for revert: Breaks a test: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792462319927467985/+/u/OptimizeForSize/CreateIsolateFromReadOnlySnapshot
Original change's description:
> [flags,testrunner] Consider readonly flags for conflict detection
>
> Flag conflict detection 1) bails out on incompatible flag values (e.g.
> --jitless and --turbofan) and 2) handles such bailouts transparently in
> the test runner by marking affected tests as OUTCOMES_FAIL.
>
> This CL adds full support for readonly flags to this system, together
> with required additional annotations in variants.py.
>
> Drive-by: assert proper use of v8_enable_slow_dchecks, and add
> support when dcheck_always_on is set.
> Drive-by: introduce has_maglev build variable detection based on
> v8_enable_maglev and use that for .status file annotations.
> Drive-by: protect against unintended overwrites of build variables
> in statusfile.py.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
> Bug: v8:13629,v8:10577
> Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85130}
Bug: v8:13629,v8:10577
Change-Id: I0cb072c6c9f05d92894cc0af83c4d1a28df100d5
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147098
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85133}
We change the breakpoint hint logic to check if the script has not
locally changed (with a hash of the source text between the requested
breakpoint location and the actual breakpoint location). If the
text did not change, we set the breakpoint at the same
location as before.
Bug: chromium:1404643
Change-Id: I6ceecf9924e699aaf37518680d1cb79d3eb00959
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4138260
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85131}
Flag conflict detection 1) bails out on incompatible flag values (e.g.
--jitless and --turbofan) and 2) handles such bailouts transparently in
the test runner by marking affected tests as OUTCOMES_FAIL.
This CL adds full support for readonly flags to this system, together
with required additional annotations in variants.py.
Drive-by: assert proper use of v8_enable_slow_dchecks, and add
support when dcheck_always_on is set.
Drive-by: introduce has_maglev build variable detection based on
v8_enable_maglev and use that for .status file annotations.
Drive-by: protect against unintended overwrites of build variables
in statusfile.py.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Bug: v8:13629,v8:10577
Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85130}
Loops can be unrolled only for innermost loops. But, the wasm graph
builder builds loop exits regardless of the condition. This CL detects
if the loop can be innermost using AnalyzeLoopAssignment, and do not
allocate unnecessary nodes if it can't be.
This reduces memory usage for the reported wasm binary from 1.3GB to
300MB.
Bug: v8:13543
Change-Id: I693800071f7eee4a9991e094830f23d27a96b13f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134466
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#85122}
This CL is exactly the same as the original CL, without changes. The
issue was a missing Isolate::Scope, and it existed already before this
CL. I fixed the issue separately in https://crrev.com/c/4136720.
Original message:
Original change's description:
> [wasm][capi] Optimize all functions before serialization
>
> The existing implementation of `serialize` in the C-API is to produce
> a snapshot of the current state of the `NativeModule`. However, so
> far all users of `serialize` did not care about the runtime of
> `serialize`, but cared about `deserialize` starting up fast.
>
> With this CL all functions of a module get tiered up to TurboFan
> before serializing the module.
R=clemensb@chromium.org
Change-Id: Ib8ed33c63c137e167fb50ccf721184b2b16cf4d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4131635
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85120}
We add a {canonical_type_index} field to tag objects and use it to
check for canonical subtyping between tags when needed.
Bug: v8:7748
Change-Id: I60723d8f72a9487af03f223c8f8a33ef8fa56461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135885
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85119}
After a call to {StreamingDecoder::NotifyCompilationEnded}, no method on
the {StreamingProcessor} should be called any more. We were still
calling the {OnAbort} method later.
To make the semantics a bit more clear, we rename
{NotifyCompilationEnded} to {NotifyCompilationDiscarded}.
We also remove the {stream_finished_} field and reset the processor
instead, which will result in a nullptr access if we try to illegally
call any further methods.
R=ahaas@chromium.org
Bug: chromium:1403531, chromium:1399790, chromium:1400066
Change-Id: I4caef3801dfe9d653125efbd7bc9b5d13ce30dc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4132966
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85114}
V8FileLogger has a dynamic behaviour when listening to
code events, i.e., it can stop listening without removing
itself from the Logger, which invalidates the field
is_listening_to_code_events_. This field is only updated
when adding/removing an event listener.
This cache was recently introduced in a refactoring
https://crrev.com/c/3582125
Bug: chromium:1400809
Change-Id: If93c88a6a64f5bf2c10265ac1db455ea498733a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4136726
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85113}
Runtime.executionContextCreated provides many details in
ExecutionContextDescription structure while
Runtime.executionContextDestroyed provides only executionContextId. This
information is insufficient for the clients that use uniqueContextId.
Bug: v8:12896
Change-Id: I31df0ed618dc1c8b55c7eba8f96eeaef2d4de6c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3657439
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Vladimir Nechaev <nechaev@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85110}
The debugger utilizes the source position while single stepping
("Step-in") through the source to go from statement to statement and
skipping some expressions along the way. The debugger remembers the
"statement position" of the last stepping action.
This works well in general but falls flat for loops that only have
a single statement in them. Every step lands on the same statement,
just one loop iteration later.
We detect this case by checking if we are in the same frame and have
the exact same bytecode offset as the last step action.
Note that this also fixes "frame restarting" should we have restarted
a function while paused at the beginning of that function.
R=jarin@chromium.org
Bug: chromium:1401674
Change-Id: Id0a5753ed7cc9f23f22d869368d88e1c4b48566d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85107}
This CL fixes a bug where we wouldn't pause (or even crash) when trying
to interrupt an infinite loop.
When we pause via stack check (i.e. a scheduled break) we currently do
one additional step-in. We do so to enter functions properly in case
we are paused in the middle of setting up the stack frame.
Loops also do a stack check, to support pausing infinite loops. In
that case we can skip the additional step-in as we are already
in a valid pause position (as implemented by this CL).
This CL also removes two bogus DCHECKs. We assumed that
a scheduled break never happens after a step. This is wrong, e.g.
a user can click the pause button after stepping over a long running
function.
Note that we duplicate the various loop interruption cctests to
also interrupt the loops with the "scheduled" break reason. Without
the changes in debug.cc, those won't pass.
The CL https://crrev.com/c/4136058 adds a regression test on the
blink side.
R=jarin@chromium.org
Fixed: chromium:1401674
Change-Id: I42b44744b17d24351f01b83c0446908c24e6c5fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134246
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85106}
Delay the "max steps" check until the frame is fully set up. This means
that the work is already done at the point where we check the maximum
number of steps, but the additional work is limited by the maximum
number of locals and parameters.
R=thibaudm@chromium.org
Bug: chromium:1404619
Change-Id: I4919c837feea92af84f99182a571edf96e4728ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135890
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85098}
The expected behavior of the optimized code is deoptimizing when using a BigInt
as an index and throwing an error (from CheckedTaggedToInt64).
The representation changer tries to insert conversions for this case where
- The output node is represented in Word64 (SignedBigInt64)
- The use info is CheckedSigned64AsWord64
The representation changer first rematerializes the output node to
TaggedPointer because the type check is not BigInt. Then it falls wrongly to
the branch where the output representation is TaggedPointer, the output type is
SignedBigInt64 in GetWord64RepresentationFor.
Bug: v8:9407, chromium:1403574, chromium:1404607
Change-Id: I9d7ef4c94c1dc0aa3b4f49871ec35ef0877efc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135876
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#85094}
Increase length of strings in the test to ensure they are cachable
external strings even when the sandbox is disabled.
Change-Id: I1228e1abb1d88c0bb70edaeb718e1bf2f4cdd53d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127228
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85081}
With lazy compilation we disabled mprotect-based code protection. We
currently have no users and no test coverage of that flag. Hence remove
it from the code base.
R=ahaas@chromium.org
Bug: v8:13632
Change-Id: I1e39499dfbdb896287901b97c32f00366449c466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4114296
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85080}
EmbedderStackStateScope is used to disable conservative stack scanning
for cppgc when the stack is known to not contain heap pointers. Also,
DisableConservativeStackScanningScopeForTesting is used to disable CSS
for the V8 heap in tests that assume a precise GC. Until now, these two
have used two different mechanisms for disabling CSS. This CL merges
the two mechanisms and implements the latter scope via the former.
This is a reland of commit f51e0bb1db
reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/4111954
Bug: v8:13257
Change-Id: Ia124a4201686e0ea79f9cd07bc3888b9781cafa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128141
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85066}
This removes EmbedderHeapTracer from V8's API. Going forward
v8::TracedReference is only supported with using CppHeap (Oilpan).
Bug: v8:13207
Change-Id: I4e0efa94890ed147293b5df69fd7e0edad45abb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111546
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85061}
When internalizing external strings, a new internalized external string object is allocated if the string is not in-place internalizable. This newly allocated strings external resource is set to null (the actual resource will be transferred by MakeThin to ensure unique ownership of the resource).
We need to preserve the original string in the InternalizedStringKey for
the second lookup (inside the critical section), as we need to access
the external resource in case of hash collisions to check for equality.
Bug: chromium:1402187
Change-Id: I62b637859b06f05d1b34cb26495f08ec44d2f2db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128089
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85057}
This reverts commit 84e470845a.
Reason for revert: Breaks TSAN stress-incremental-marking: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10433/overview
Original change's description:
> [wasm][capi] Optimize all functions before serialization
>
> The existing implementation of `serialize` in the C-API is to produce
> a snapshot of the current state of the `NativeModule`. However, so far
> all users of `serialize` did not care about the runtime of `serialize`,
> but cared about `deserialize` starting up fast.
>
> With this CL all functions of a module get tiered up to TurboFan before
> serializing the module.
>
> R=clemensb@chromium.org
>
> Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85052}
Change-Id: Ie0758b32ef3469fe75d3a45bc3e6950b3b192edb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4131634
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85053}
The existing implementation of `serialize` in the C-API is to produce
a snapshot of the current state of the `NativeModule`. However, so far
all users of `serialize` did not care about the runtime of `serialize`,
but cared about `deserialize` starting up fast.
With this CL all functions of a module get tiered up to TurboFan before
serializing the module.
R=clemensb@chromium.org
Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85052}
TurboAssembler::Switch considers its "condition" input is 64-bit.
However, Maglev's inner integers are rather Smis/32-bit integers.
Because we didn't not sign-extend the condition before calling
TurboAssembler::Switch, negative values were treated as positive
rather than negative.
Fixed: chromium:1403749
Bug: v8:7700
Change-Id: I78e934045330012186dc83dea0dc620ec977380a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128080
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85049}
`CpuProfiler::StopProfiling()` return `nullptr` if no profiling is
active. Thus a `nullptr` check is needed before serializing the profile
returned by `CpuProfiler::StopProfiling()`.
R=clemensb@chromium.org
Bug: chromium:1394663
Change-Id: I364eeb1d9bd670de5179e242c4462f0fbfc9c607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4126234
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85047}
.. which should result in 0 if x is non-negative, and -0.0 otherwise.
- Fix two invalid modulus-related folds.
- Handle aliased inputs in Int32ModulusWithOverflow.
- Drive-by: rename left/right to lhs/rhs to match the algorithm
description.
Note there is no deopt loop here since a result of -0.0 will update
feedback to kSignedSmallInputs.
Bug: v8:7700
Change-Id: I84fca0e43ded152d3520cbe73cc43299ff1c4230
Fixed: chromium:1403575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128081
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85039}
The Sub macro sometimes needs a scratch register when the 2nd operand
is too large to be encoded in the instruction. The prologue was
already reserving 2 scratch registers, which made Sub crash on a
DCHECK when trying to reserve one more scratch register.
Bug: v8:7700
Change-Id: I995689b8b16e3ef216641f0b6cadbf58f7f3740b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128554
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85029}
Mark rhs as clobbered since we may negate it. Negate the lhs in rax.
Bug: v8:7700, chromium:1403470
Change-Id: I9a26de78fcd8d1db90c1d26617001c0c699c350e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110814
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85021}
As a drive-by this also fixes property load from smi. We still need to check that we actually have a smi...
Bug: v8:7700, chromium:1403280, chromium:1403323
Change-Id: I3c4f050b94550b8d7e4e65f733f9c1dad47941d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120575
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85015}
Even if we have a constant load, if the map is not stable, we cannot
guarantee that the load is preserved across side-effecting calls.
Fixed: chromium:1403324
Bug: v8:7700
Change-Id: Ib900cf7574711115439e6521ed8cfaa866525e78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123532
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85014}
It's possible that various branches merged already with a value that's
in a liveness hole, but we only figure out later. If so, drop the merge
as well.
Bug: v8:7700, chromium:1403399
Change-Id: Ifd97e0c1959ffe51017e400fb028041047885a9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111932
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85013}
The issue causing this test to fail on the usban bot was fixed with
https://crrev.com/fcda478d890caea6bf04a50e6106682b64cf8d5a
Bug: v8:13611, v8:13612
Change-Id: I1d0a713160cdddf8623e767d43277a988509bce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110955
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85007}
This CL plugs the hole in the outside<-ShadowRealm direction (i.e.
getting a reference to an object inside of the ShadowRealm from outside
the ShadowRealm).
This is a follow-on CL to
https://chromium-review.googlesource.com/c/v8/v8/+/4108810, which
plugged the getFunction hole in the ShadowRealm<-outside direction (i.e.
getting a reference to an object outside of the ShadowRealm from inside
the ShadowRealm).
Bug: v8:1198
Change-Id: Ic06533ba8b1cc6477ef9d55a23cb8b0b6584d4a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4115657
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85003}
With smi feedback, we use int32 operations for arithmetics.
When negating 0, we have to fallback to float as we can't represent -0
in int32. We can simply deopt in that case without causing a deopt loop, as a non-smi result will change the feedback to kSignedSmallInputs (from kSignedSmall).
Bug: chromium:1403102
Change-Id: Ic27c267349a1de6904639e91b1cade2c4f7d1fe2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122829
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84998}
This CL introduced four more operators in TurboFan: BigIntLessThan,
BigIntLessThanOrEqual, and the corresponding speculative operators so
that all the BigInt comparisons are supported.
This CL also implemented fast paths for small BigInt inputs.
Bug: v8:9407
Change-Id: Iaa2d4dbebf68656d775a7feb65b97fb5c598ec23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111951
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84995}
After https://crrev.com/c/3859787 those frames would be printed like
standard Wasm frames, but in the place of the WasmInstanceObject, they
have a WasmApiFunctionRef object instead.
So special-case the {WasmToJsFrame::instance()} to load the instance
properly. Also special-case the {position()} accessor for imported
functions.
R=victorgomes@chromium.org
Bug: chromium:1402270
Change-Id: I39805805a50e7a73d7d8075c63c46bdf5a373a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116778
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84993}
It's failing regularly on the ubsan bot, closing the tree.
This CL also adds a 'variant == future' section in the mjsunit.status
file to enable easy disabling of maglev-specific failures.
No-Tree-Checks: true
Bug: v8:13612
Change-Id: I3c0f7725e1fb36577e97c662cd3830c64ba298e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120554
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84982}
This reverts commit 2a71e8637f.
Reason for revert: This probably blocked the V8 roll.
https://chromium-review.googlesource.com/c/chromium/src/+/4116621?tab=checks
Original change's description:
> Reland "[heap] Fix conservative stack scanning for client isolates"
>
> This is a reland of commit 36bac1bcae
>
> Original change's description:
> > [heap] Fix conservative stack scanning for client isolates
> >
> > With this CL, the context of stacks corresponding to all client isolates
> > are saved, so that conservative stack scanning can be used correctly
> > during a shared garbage collection. This happens:
> >
> > 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> > isolate and the initiator;
> > 2) when an isolate's main thread is waiting in a safepoint; and
> > 3) when an isolate's main thread is parked.
> >
> > Bug: v8:13257
> > Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#84712}
>
> Bug: v8:13257
> Change-Id: I61df6eeca5a28e04eb3a858f7d601bc5f6312e49
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092737
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84963}
Bug: v8:13257
Change-Id: I3a235f11e5fe55c476591a5274946aeb6cc9bf6e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111178
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84973}
This reverts commit f51e0bb1db.
Reason for revert: Dependent on crrev.com/c/4092737 that is being reverted.
Original change's description:
> [heap] Merge mechanisms for disabling CSS
>
> EmbedderStackStateScope is used to disable conservative stack scanning
> for cppgc when the stack is known to not contain heap pointers. Also,
> DisableConservativeStackScanningScopeForTesting is used to disable CSS
> for the V8 heap in tests that assume a precise GC. Until now, these two
> have used two different mechanisms for disabling CSS. This CL merges
> the two mechanisms and implements the latter scope via the former.
>
> Bug: v8:13257
> Change-Id: Ieca082657854fe2eff9eb5d95a30d48bb8eab44f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111954
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84964}
Bug: v8:13257
Change-Id: Id769af6215a2ed319ec96b354734a5362b2384cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111179
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84972}
EmbedderStackStateScope is used to disable conservative stack scanning
for cppgc when the stack is known to not contain heap pointers. Also,
DisableConservativeStackScanningScopeForTesting is used to disable CSS
for the V8 heap in tests that assume a precise GC. Until now, these two
have used two different mechanisms for disabling CSS. This CL merges
the two mechanisms and implements the latter scope via the former.
Bug: v8:13257
Change-Id: Ieca082657854fe2eff9eb5d95a30d48bb8eab44f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111954
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84964}
This is a reland of commit 36bac1bcae
Original change's description:
> [heap] Fix conservative stack scanning for client isolates
>
> With this CL, the context of stacks corresponding to all client isolates
> are saved, so that conservative stack scanning can be used correctly
> during a shared garbage collection. This happens:
>
> 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> isolate and the initiator;
> 2) when an isolate's main thread is waiting in a safepoint; and
> 3) when an isolate's main thread is parked.
>
> Bug: v8:13257
> Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84712}
Bug: v8:13257
Change-Id: I61df6eeca5a28e04eb3a858f7d601bc5f6312e49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092737
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84963}
The spec does not allow side effects on wrapping the exceptions
crossing the realm boundaries. We need to provide an easy way to inspect the exception-thrown cross-realms according to the last TC39 meeting
consensus.
Related spec change: https://github.com/tc39/proposal-shadowrealm/pull/382.
Bug: v8:11989
Change-Id: Ia78d94fd33cba689267aeacd028d662bd4a37fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3618759
Commit-Queue: Chengzhong Wu (legendecas) <legendecas@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84961}
With this change property accesses on WasmObject and WasmArray return
undefined instead of throwing.
Furthermore retrieving the prototype of a WasmObject/WasmArray returns
null.
Bug: v8:13523
Change-Id: I12e3b9fb6ac9a7305f001a3b3835854068c3064f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110995
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84957}
We add final types to wasm-gc.
- We introduce a `kWasmSubtypeFinalCode` as an alternative to
`kWasmSubtypeCode`.
- Behind a flag, we interpret types behind this code as final, as well
as types outside a subtype definition by default.
- For final types, type checks for call_indirect and ref.test etc. are
reduced to simple type identity checks.
Bug: v8:7748
Change-Id: Iabf147b2a15f43abc4c7d1c582f460dbdc645d66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096478
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84955}
Error mode: a TypedArray backed by RAB claims it's not backed by RAB.
Drive-by: disable resizability even harder when --harmony-rab-gsab is
not on.
Bug: v8:11111, chromium:1402139
Change-Id: I937c69f6124419cc8d29da0195686bc3b9a5c281
Fixed: chromium:1402139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110751
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84952}
- Converts tests in EmbedderTracingTest to UnifiedHeapTest
- Move EmbedderRootsHandler tests to their own file
- Adds support for CppHeap in ManualGCScope
- Drive-by fix typo
Reland: Fix issue with attaching a CppHeap while incremental marking
is already running.
This reverts commit d90a98edc1.
Change-Id: Ifafa9145df3103578c4c7f1b3b0336b4bd9f34dd
Bug: v8:13207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110941
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84950}
ShadowRealms have a callable boundary: there cannot be any edges between
objects in the ShadowRealm and those from other realms. V8's
prepareCallStack API breaks this invariant via getFunction() and
getThis(). This CL makes those functions throw when called inside
ShadowRealms.
See also
https://docs.google.com/document/d/1aXEy4YCC9CduxLs7MGw-UOm0P4OuG7W-cScBnLG3ALI/edit?usp=sharing
Bug: v8:11989
Change-Id: I5a2b8fa735c0f10583c8cede4062645986b2d914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108810
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84944}
All IFS values of resumable loops are loop phis, so values from before
the loop can safely be dropped. In fact, if we don't drop them we might
not be able to restore them and crash in a safety check. Eagerly
dropping the values allows us to keep the safety check.
Bug: v8:7700
Change-Id: I99ef80e35db5aba965dc1c5c9d78f1d085e589fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110940
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84943}
Usually sharable strings are automatically promoted to shared old space
and can be shared in-place.
There are currently two exceptions:
- When using a non-moving GC (e.g. minor MC)
- Strings in LO space
Account for these exceptions by copying strings to the respective shared
space when sharing them.
Bug: chromium:1400048
Change-Id: I20713b5f32f449c14febd848e289b5767530a257
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110752
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84942}
We use 0xffffffff as a sentinel for "no supertype". Therefore we
should reject it as we parse it. We implement this by rejecting
supertypes outside V8's type definition limit.
Bug: v8:7748
Change-Id: I7942d94073d8f7350528fb0e364e91f7359c8cec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110750
Auto-Submit: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84934}
Aligning struct fields to multiples of their own size can leave gaps
between them, e.g. when i8 and i32 fields alternate. This patch
introduces a simple optimization: it keeps track of the most recent
such gap, and attempts to use it for later fields that are small enough.
Bonus changes:
- Cap field alignment to 4 bytes (because we only have 4-byte object
alignment anyway).
- Don't re-compute field offsets when canonicalizing types. Instead,
re-use the original type's offsets.
Bug: v8:7748
Change-Id: Iabfc8e7cda94f16d196ed4429f3aa92d249b3b72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092494
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84933}
This (test-only) runtime function only supported unoptimized frames as
callers. Add support for Maglev frames as well by extracting the
relevant BytecodeArray and bytecode offset.
This reverts commit 955de73ee5.
Bug: chromium:1400549,v8:7700
Change-Id: I80f80f8736ff0400d6d47e355add2a07cdc4559e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111851
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84931}
This is a reland of commit 5d95bd39ca
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Id9d1a1ab2dc36e481287a1a25863b45bf281920c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110746
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84928}
This reverts commit 5d95bd39ca.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20gc%20stress/2101/overview
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Ib82d06ab8281f0e59a2af2b631bf93b25064df1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110745
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84925}
The problem was that synchronous Maglev OSR potentially caused
code deoptimization during compilation dependency finalization; this
led to a lazy deopt when returning from the call to
Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
is already marked as eager deopt since that's how OSR is implemented
under the hood. See also the comment in runtime-compiler.cc.
We fix this by changing synchronous Maglev-to-Turbofan OSR
behavior s.t. actual OSR compilation is triggered from Ignition
(and not from Maglev). In other words, when synchronous OSR is
requested:
1. trigger an eager deopt from Maglev to Ignition by returning a
non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
2. Ignition handles the pending OSR compile request (through
osr_urgency).
This CL also reverts previous partial fixes:
This reverts commit 21969e8e24.
This reverts commit 6bcbcfed5c.
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84922}
There was a concurrency issue `WasmEngine::EnterDebuggingForIsolate`
which gets fixed by this CL. When multiple isolates entered debugging
concurrently, then only the first CL that changes the debug state of
a NativeModule would remove all compiled code from the NativeModule.
However, changing the debug state and removing the compiled code would
not happen atomically inside a lock. Instead, first the debug state
gets changed inside the lock, and then the compiled code gets removed
outside the lock. The concurrency issue is now the following.
Assume isolate A enters debugging. It takes the lock, and then changes
the debug state. As it changes the debugging state, it is the task of
isolate A to delete all code. Concurrently isolate B also enters
debugging. It sees that the debug state is already changed to debug
state and therefore just continues execution without removing code
first. In the following execution of isolate B non-debug code may get
executed if isolate A is slow with removing the code.
This CL fixes the issue by adding a filter to `RemoveCompiledCode`, and
then letting all isolates remove compiled code according to the filter.
This means that isolate B would also iterate over all the code and
remove all functions which are non-debug functions. This guarantees
that isolate B does not execute non-debug code that existed before
isolate B entered debugging.
R=clemensb@chromium.org
Bug: v8:13541
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Change-Id: If688c7f9b15f78e6cd6898123a321e577d32365f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111524
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84919}
The previous fix from
https://chromium-review.googlesource.com/c/v8/v8/+/4086127 was
insufficient. It prevented shared objects from being optimized as
prototypes, but callers of OptimizeAsPrototype also assume that all
JSObjects can track prototype users via prototype_info on the map.
This CL attempts a broader fix where shared objects are not considered
optimizable as prototypes at all. When used as a prototype, shared
objects are treated like non-JSObjects (e.g. JSProxy, WasmObject).
Bug: chromium:1401295, v8:12547
Change-Id: I9886e9ccac9e597e7dd34a09083a096ff4e3bf16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112150
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84916}
This CL avoids unnecessary heap allocation for BigInt64 array
store/load by
- setting the output representation of a load to word64, and
- propagating word64 truncation to the source of a store.
This CL introduces a simplified operator SpeculativeToBigInt
which is applied to the source of a store to a BigInt64 array to
deopt on a non-bigint input.
Bug: v8:9407
Change-Id: I48ce13761bc4cf742d5b18cec4476dc9ad131414
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4101011
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84908}
Certain optimization phases are more convenient to write when they
can run before Int64Lowering. So this patch moves Int64Lowering
from graph building to a later point in the pipeline.
The logic itself is not changed, and no impact on performance or
behavior is expected.
Change-Id: I3597498e8f3bb9e6fa8c3b36dcfcc735440f80b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111237
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84907}
Optimize FastDtoa, in particular Grisu3. In addition to making
a microbenchmark, there are a number of smaller and larger
changes here:
- Replace divisions by power-of-ten with multiplications by
their inverses, using an algorithm very similar to the one
in libdivide.
- For DiyFp::Times(), use 128-bit hardware multiplication
if available (which it generally is on 64-bit platforms).
- Where possible, send around a pointer to the end of the string,
instead of a pointer and a length, reducing register pressure
(especially for Intel). Where not (easily) possible, add
a local variable to make the compiler understand that length
and decimal_point cannot alias.
- Change some ints to unsigneds where it helps us avoid sign
extensions.
- Some minor changes to reduce instruction dependency chains.
- Inline BiggestPowerTen().
Actual performance gain is wildly different between platforms.
On my 3990X workstation (Zen 2), gains are about 21%. On a M1
Mac Mini, they are about 17%. But on my i7-10610U laptop
(Comet Lake, so Skylake microarchitecture), the function is
78% faster. This is probably because large divisions
(divisor over 255) seem to hurt a lot on Skylake, but I haven't
gone through it in detail.
Change-Id: I5b67c257d788a3f7d1be7065d055456852451d68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110741
Commit-Queue: Steinar H Gunderson <sesse@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84906}
This CL adds subtyping support to call_indirect: signature comparison
for call_indirect will now succeed if the real signature of the table
element is a canonical subtype of the declared signature. This makes
wasm-gc semantics strictly more permissive, i.e., less programs will
trap.
Drive-by: Since liftoff call_indirect became more complex, we try to
make it a little more readable by renaming registers.
Bug: v8:7748
Change-Id: I42ba94161269e3a4535193d18bf00b3423e946bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3937466
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84903}
EmbedderRootsHandler is still supported.
Bug: v8:13207
Change-Id: I91107a2ed8c9603b77ae3e487f396c9ba32f3f95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111523
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84899}
This CL handles the conversion from Float64 (MinusZero) to Word64 in
the representation changer.
In the original CL, the range of Numbers eligible for optimization was
incorrectly set to Integral32OrMinusZero. This CL narrows it down to
Signed32OrMinusZero or Unsigned32OrMinusZero (but not the union).
Bug: v8:9407, chromium:1400897
Change-Id: I0f09eb512e77b145b081ad5d52ca03f61d49dc62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110761
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84896}
This CL implements a new %CheckTurboshaftTypeOf(e, type_string)
intrinsic allowing tests to express that the expression e is supposed
to have the turboshaft type expressed by type_string eventually during
lowering.
Test that use this intrinsic are verifying implementation details and
are thus somewhat brittle and potentially platform depedent. This
intrinsic is not supposed to be used broadly, but rather to write
some tests that check the precision of turboshaft's new type system.
This intrinsic may be removed once the type system is shipped and gets
coverage in other ways.
Bug: v8:12783
Change-Id: I4cc2582273f3d668601a3203c400a8461b470cac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061889
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84894}
For asm.js functions, the script name is used as the `source_url` for
code logging. If the script name was undefined, as it can happen for
asm.js code that gets evaluated in an eval, then `nullptr` was used
as the `source_url`. The problem was, the logging code accessed
`source_url` unconditionally, which caused a segfault.
With this CL the empty string is used as `source_url` instead of
`nullptr`.
The test revealed another problem in the isolate mode: profiling has
to be stopped and the profiler disposed before the isolate dies.
R=clemensb@chromium.org
Bug: chromium:1395401
Change-Id: Ia9730bb033a22b799ea2b1903ea540db9f259513
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079685
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84892}
This reverts commit fffae64444.
Reason for revert: Causes failures since an isolate in state
TEAR_DOWN might still park itself.
Original change's description:
> [heap] Ignore client isolates that are tearing down
>
> Client isolates that tear down only participate in the safepointing
> protocol to remove themselves from the list of all clients without
> blacking global safepoints.
>
> However, we do not need to consider them for the root set since such
> isolates will just detach as soon as possible and therefore are not
> allowed to touch the shared heap anymore anyways.
>
> This fixes a heap verification bug where heap verification fails for
> an isolate that tears down fails because the external string table
> was already finalized.
>
> We also can't move external string table finalization after detaching
> since then we would have races on the shared external pointer table.
>
> Bug: v8:13267, chromium:1401078
> Change-Id: I7d97c2d223bd87f620d9a92a9266be7b88afd9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110857
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84870}
Bug: v8:13267, chromium:1401078
Change-Id: I0c9fb1adad850b834a79cb64e535051c30762397
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112005
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84886}
This stores the CallDescriptors used for i64 <-> BigInt conversion
builtins as process-globals on the WasmEngine, instead of creating
them as temporaries whenever they're needed.
The primary purpose of this change is to simplify the interface to
the Int64Lowering by eliminating its "special case" parameter, in
preparation for moving that lowering to a different point in the
compilation pipeline.
A minor secondary benefit is that this will save a little bit of
(repeated) Zone memory usage.
Bonus change: drop the Int64Lowering from 64-bit builds, where it
isn't used, but was compiled in up to now. This saves ~17 KiB on
Android-arm64 builds.
Change-Id: Ib35d2e0f772110652eb05abd4c42d848108164b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110898
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84884}
My plan is to add a finch flag to the chrome side. It'll be a kill
switch, but given the history with changing the implementation, I want
to make sure we have the ability to switch back.
Bug=v8:13477
Change-Id: I1559e10d134bd78699b1119be26934570c6e5241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108811
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84874}
Three issues were fixed:
* In debug state, only publish debug code.
* When entering debugging in an isolate, only delete the code of
those NativeModules that aren't in debug state already.
* When async compilation finishes, only throw away code if the debug
state changed during compilation.
Original message:
Currently V8 recompiles all functions of a WebAssembly module when a
debugging session starts. This is outdated behavior and
causes OOMs for developers. With this CL all compiled code just gets
removed when a debugging session starts, and debugging code gets
compiled lazily.
This behavior may lead to small delays whenever a new function gets
entered by the debugger. However, developers are used to debugging code
being slightly slower, and the small delays should be in the order of
few milliseconds. On the other hand, debug modules can be big,
sometimes even more than 1'000'000 functions, and developers reported
OOMs when debugging.
R=clemensb@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ie27388a287cd16a67a483e14fc22c2ab4180962e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079190
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84873}
Client isolates that tear down only participate in the safepointing
protocol to remove themselves from the list of all clients without
blacking global safepoints.
However, we do not need to consider them for the root set since such
isolates will just detach as soon as possible and therefore are not
allowed to touch the shared heap anymore anyways.
This fixes a heap verification bug where heap verification fails for
an isolate that tears down fails because the external string table
was already finalized.
We also can't move external string table finalization after detaching
since then we would have races on the shared external pointer table.
Bug: v8:13267, chromium:1401078
Change-Id: I7d97c2d223bd87f620d9a92a9266be7b88afd9c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110857
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84870}
The destructor for BackgroundMergeTask checks that the task doesn't have
pending foreground work. However, there are valid cases where the task
can be abandoned without completing its foreground work, either because
another copy of the same script showed up in the Isolate compilation
cache or because the serialized code data had an incorrect source hash
and was rejected. This change removes the problematic DCHECK and adds a
new one in code-serializer.cc at a point where we can actually be sure
there isn't pending foreground work.
Bug: chromium:1400781
Change-Id: Idb3538229d25f297adf5b2696c4b4b50d85557b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4105926
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84869}
Adds new `br_on_cast_fail null <branch depth> <heap type>` instruction
with opcode 0xfb4b.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: Ieb7322a31fd2b5f64a669193003a365149bef34e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085008
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84868}
This includes the class name of the target object as part of the
description for Proxy objects, i.e. `Proxy(HTMLElement)` for proxies
whose targets are `HTMLElement`s. This greatly improves the debugging
experience with proxies, which are becoming more common these days (for
example with Vue using proxies for their components).
Before: https://imgur.com/SbR4s6H.png
After: https://imgur.com/NWQJFj8.png
Fixed: chromium:1400253
Change-Id: I3bd2b0f91a3aeaa531d5e5dd2ca3e777e4663ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4109729
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84864}
The current version of CloneAndInlineBlock assumes that the inlined
block is a direct predecessor of the currently reduced block. With
recent Return reductions implemented in branch elimination that's no
longer the case, as we're looking one edge past the current block.
Bug: chromium:1399626
Change-Id: I2ce23672c0e33b2857a4663d8e7ad5ed1df3c20e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4097125
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84862}
Since its introduction (behind a compile-time flag), conservative stack
scanning was disabled by default on tests. This CL inverts this logic,
enabling CSS by default for all tests that do not define an explicit
scope to disable it.
Bug: v8:13257
Change-Id: I5ea4249d02f69b0b1e195415c2562daf5d8c0ea9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100912
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84848}
The CL applies multiple changes:
1) Reverts back to using std::vector<> for young nodes. Distinguishing
between young and remembered nodes is still needed to allow fast
filtering.
2) Adds the has-old-host flag to TracedNode, which is used to remember a
node.
3) Adds bailouts for old objects into UnifiedHeapMarkinState and
ConservativeTracedHandlesMarkingVisitor.
Bug: v8:13475
Change-Id: Ib296ece9df6f783bb3d47ffa0794be16e6c1aea8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080386
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84839}
This CL adds support for BigIntEqual in turbofan and collects type
feedback for small BigInt equal and strict equal in ignition.
Bug: v8:9407
Change-Id: I29cbc4d3bdfe9fcde8c1717afe83654a84c25c36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096557
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84832}
This is a reland of commit 303facf5e1
This CL fixes DCHECK failures by using BasicMemoryChunk in
RecordOldToSharedSlot.
Original change's description:
> [heap] Also promote strings in large objects into shared heap
>
> With --shared-string-table all in-place internalizable strings are
> directly promoted from new space into the shared heap. However, this
> wasn't the case with large objects. This CL fixes this and adds test
> to guide fuzzers.
>
> Bug: v8:13267, chromium:1400048
> Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84805}
Bug: v8:13267, chromium:1400048, v8:13588
Change-Id: I221592ec723d2b5e92094ff2598a99576d72a677
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4098831
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84830}
Currently, any session can resume instrumentation breaks by sending
Debugger.resume command. That can lead to unreliable breakpoint
placement because sessions can resume too early.
The early resumption can happen in two ways:
- When we have two instrumented sessions, the first one to resume
can prevent the other one from setting its breakpoints
before executing the code.
- With one instrumented session and one without instrumentation
breakpoints, the uninstrumented session's Debugger.resume
command can resume the instrumentation pause before the
instrumented session can set its breakpoints.
This patch fixes both of these issues by changing the instrumentation
pause resumption logic to take note of the sessions that were notified
about the instrumentation breakpoints. The debugger will only resume
once all those sessions resume (or disconnect).
Bug: chromium:1354043
Change-Id: I84cf16b57187dbb40645b2f7ec2e08f0078539dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100466
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84827}
This CL adds v8::ArrayBuffer::NewResizableBackingStore.
This API is needed to support Mojo cross-process serialization of
resizable buffers. See https://chromium-review.googlesource.com/c/chromium/src/+/4086949
Bug: chromium:1396361, v8:11111
Change-Id: I1d3ad367f28015184fd80fd2f05a37a3659d3a66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4093555
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84826}
Asm.js code (translated to Wasm) is valid by design, do not try to
validate it.
This is achieved by fully populating the {validated_functions} bitset
for asm.js modules. To make this safe(r) we do not allow to change the
origin or a WasmModule after initialization, which requires some
refactoring mostly in tests.
R=ahaas@chromium.org
Bug: v8:13447, v8:13565
Change-Id: I174c01f13185ff4117b02882b953c6ba29a3644d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100686
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84824}
This reverts commit 303facf5e1.
Reason for revert: Causes failures with fuzzers.
Original change's description:
> [heap] Also promote strings in large objects into shared heap
>
> With --shared-string-table all in-place internalizable strings are
> directly promoted from new space into the shared heap. However, this
> wasn't the case with large objects. This CL fixes this and adds test
> to guide fuzzers.
>
> Bug: v8:13267, chromium:1400048
> Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84805}
Bug: v8:13267, chromium:1400048
Change-Id: If20528bbf804b73ce8ad10f8addc9a1f11b50d96
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4101261
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84813}
The "is there enough data" check has to be done *after* reading
maxByteLength.
Bug: v8:11111, chromium:1400431
Change-Id: I7c2eddaeb998f3cd3919e118c093a5d036fca408
Fixed: chromium:1400431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100468
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84809}
With --shared-string-table all in-place internalizable strings are
directly promoted from new space into the shared heap. However, this
wasn't the case with large objects. This CL fixes this and adds test
to guide fuzzers.
Bug: v8:13267, chromium:1400048
Change-Id: I6f850d480956c63bfbe1a7060140df850e284933
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096818
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84805}
Code objects are linked in a custom per-native-context weak list of
optimized code (previously there was also a list of deoptimized code,
but this was recently removed).
There used to be reasons for this list, but at this point it is only
used by the debugger to mark code for deoptimization. The debugger can
do this with a heap walk instead, so we can remove this list and indeed
the next_code_links from Code objects themselves.
Change-Id: Iebbed4adacd31b8ddc442ae6355ea45c691cc856
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061515
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84804}
This patch moves the stop method from context group to session to enable
stopping each session independently. This is useful for testing that
stopping does not interact badly with other sessions.
Bug: chromium:1354043
Change-Id: I885cf49f2d4cf006fa5228edf2954099e45cfc6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4100484
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84797}
This CL fixes two bugs:
- The monotonicity violation in the typers of ToBigIntConvertNumber and
Integral32OrMinusZeroToBigInt.
- The missing handling of conversion from Tagged output with the type
DoubleRepresentableInt64OrMinusZero to Word64.
Bug: v8:9407, v8:13580, chromium:1399951, chromium:1400053
Change-Id: I669820b52e5b82bddc9853cfd97a2361c344a2cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096990
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84793}
We already exclusively use the WasmEngine's AccountingAllocator for all
decoded Wasm modules. Except for tests, the same allocator will also be
used for validation. Thus do not pass it down explicitly, but get it
from the WasmEngine when needed.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Idaa9d6c3e0ab0051bf85bb2667accac89e8b5607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84792}
A new test added in https://crrev.com/c/4092575 times out on ASan
windows builds and is slow.
Superseeds https://crrev.com/c/4096677.
No-Tree-Checks: true
No-Try: true
Bug: v8:13466
Change-Id: I40d61459437434cf739fbff8c223871012a23010
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096817
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84784}
The current reduction of blocks that are branch targets with a known
condition assumes that this is the first time we're seeing the given
condition with the given value. That's no longer the case, so updating
the expectation accordingly.
Bug: chromium:1399627
Change-Id: Id84d80a38801cf6178b476e62160d616b948d8d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096984
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84780}
This is required to be spec-compliant.
The previously implemented behavior was more relaxed allowing one to use
`ref.cast null` on non-nullable inputs and still getting a non-nullable
result on cast success.
Bug: v8:7748
Change-Id: I1297314389b0445a7c8d5a74f37d07a723d7a133
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4091549
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84776}
This is a reland of commit 331c577e1d
Fix DCHECK for single generation builds.
Original change's description:
> [static-roots] Allow creating isolates from existing r/o snapshot
>
> This adds the ability to create an isolate from scratch, except the
> read only roots, which are initialized from a read_only_data snapshot.
> To do this we split the heap setup in a read/only part and the rest.
> The goal of these changes is to later support writing serializer tests,
> even if the read only roots are static and have to be loaded from a
> fixed snapshot.
>
> Bug: v8:13466
> Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Olivier Flückiger <olivf@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84750}
Bug: v8:13466
Change-Id: Ic680b7620fc3176260c5d550e474412afef5f598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092575
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84773}
The previous fix was using the wrong getter for accessing the length.
It also threw an error when the created TA was length-tracking but in
bounds.
Bug: v8:11111,chromium:1399799
Change-Id: I5a94b1b49b2e30cf33999be7ff0ee8e4f5323849
Fixed: chromium:1399799
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090984
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84771}
I originally thought MaxByteLength would only be needed for
v8::ArrayBuffer and v8::SharedArrayBuffer, but it is also needed on
v8::BackingStore.
In particular, blink uses Mojo to serialize ArrayBuffers' contents via
v8::BackingStore when doing cross-process postMessage.
Bug: chromium:1396361, v8:11111
Change-Id: I86d44829175ad760fb43294d386483a16044fc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090708
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84767}
Array.toReversed always creates properties even for holes, but the
optimization paths for HOLEY_* arrays did not respect the spec. This CL
fixes the fast paths to set `undefined` value instead of the hole.
Bug: chromium:1395672
Change-Id: I51584829caf312a1864f93928315782bb120ee14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081689
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84766}
This CL introduces two JS operators JSToBigInt and
JSToBigIntConvertNumber and one simplified operator
Integral32OrMinusZeroToBigInt.
- BigInt constructors are lowered to JSToBigIntConvertNumber in the
inlining phase.
- JSToBigIntConvertNumber is replaced with
Integral32OrMinusZeroToBigInt if the input is typed as Integral32
in typed lowering.
- In simplified lowering, Integral32OrMinusZeroToBigInt is lowered
to conversion to word64 accordingly.
- If the input is not Integral32 or BigInt, JSToBigIntConvertNumber
is lowered to a builtin call in generic lowering.
Bug: v8:9407
Change-Id: I8539d742e82cce515bd9350797f5f9b0876ee6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#84761}
Similar to the `AsyncFunctionReject` builtin, the
`AsyncGeneratorReject` should also mark the promise rejection as a
non-debuggable event.
That is because the initial throw that causes the generator rejection
downstream alreay triggered the debuggable event.
We can re-use one of the existing tests as a regression test here:
If we wait for the Runtime.evaluate promise to resolve after the first
pause, we ensure that we already paused once. The test in its current
form swallowed the second pause implicitly by disabling the debugger.
R=bmeurer@chromium.org
Bug: chromium:1270780
Change-Id: I97ab08934804fefd097e9bd01081469da5379154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084925
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84756}
On Mac, we spend around 30% of lazy compile time in {ThreadTicks::Now}.
On Linux it's less severe, but still around 10%.
That's too much overhead for measurements that only show up in UKM, so
remove that.
The unused fields will be removed from the UKM events after the plumbing
on the chromium side has been removed.
R=ahaas@chromium.org, mlippautz@chromium.org
CC=ecmziegler@chromium.org
Bug: v8:13565
Change-Id: I2dad88d899482801888940499d2d1761ff075578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078966
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84754}
We introduce V8InspectorSession::stop API to enable safe
detach from the session. In particular, after calling 'stop',
the session will leave any instrumentation pause it might
be in and disarm all its instrumentation breakpoints.
This is useful when the session disconnect request is registered
on V8 interrupt (so it is unsafe to disconnect at that point),
and the execution should first get to the message loop
where the disconnect can be handled safely.
Bug: chromium:1354043
Change-Id: I3caab12a21b123229835e8374efadc1f4c9954c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085143
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84753}
This reverts commit 331c577e1d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation%20-%20builder/9912/overview
Original change's description:
> [static-roots] Allow creating isolates from existing r/o snapshot
>
> This adds the ability to create an isolate from scratch, except the
> read only roots, which are initialized from a read_only_data snapshot.
> To do this we split the heap setup in a read/only part and the rest.
> The goal of these changes is to later support writing serializer tests,
> even if the read only roots are static and have to be loaded from a
> fixed snapshot.
>
> Bug: v8:13466
> Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Olivier Flückiger <olivf@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84750}
Bug: v8:13466
Change-Id: I91512140abb98993578d27e65e6080e1d3f317e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4089967
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84751}
This adds the ability to create an isolate from scratch, except the
read only roots, which are initialized from a read_only_data snapshot.
To do this we split the heap setup in a read/only part and the rest.
The goal of these changes is to later support writing serializer tests,
even if the read only roots are static and have to be loaded from a
fixed snapshot.
Bug: v8:13466
Change-Id: I078695b95710e5281da013ca0c08af0e153b4725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037271
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84750}
This reverts commit 36bac1bcae.
Reason for revert: This possibly caused clusterfuzz issues and test flakiness.
Original change's description:
> [heap] Fix conservative stack scanning for client isolates
>
> With this CL, the context of stacks corresponding to all client isolates
> are saved, so that conservative stack scanning can be used correctly
> during a shared garbage collection. This happens:
>
> 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> isolate and the initiator;
> 2) when an isolate's main thread is waiting in a safepoint; and
> 3) when an isolate's main thread is parked.
>
> Bug: v8:13257
> Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84712}
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:13257
Change-Id: I7eb50b24243084d45b3f1bcc37a559b9f92e0318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092363
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84749}
This was a slightly overzealous optimization that ended up being more
tricky than expected without measurable value on the benchmarks (as far
as we know). Let's try to remove it and see whether an important
benchmark notices.
Bug: chromium:1385941
Change-Id: If2e81f6cb6758f9c373e7c2c8beaa308ed323f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4088624
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84739}
Adds new `br_on_cast_fail <branch depth> <heap type>` instruction
with opcode 0xfb43.
The instruction branches if the cast fails. `null` is treated as a cast
failure (meaning the branch is taken).
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: I97a78d6d0872703ab825016cab4e737f8f79995f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084981
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84733}
Specifically, the methods in {WasmJSFunction} and {WasmCapiFunction}.
Drive-by:
- Fix a bug in {WasmCapiFunction::GetSignature}.
- Fix a bug in wasm-module-builder.js.
Bug: v8:7748
Change-Id: I7408d07766536ed37f23b97ad210212b986412bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079097
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84728}
Keep the ValueSerializer version number the same but add a separate
value type for resizable ArrayBuffers.
Bug: v8:11111
Change-Id: I895e9ffcc63cce2e83a09d4be81312fdcffa67f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4083067
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84718}
Adds v8::[Shared]ArrayBuffer::MaxByteLength and
v8::BackingStore::IsResizableByUserJavaScript.
This is needed for embedders who need to check if a buffer is resizable
by user JS, like blink, to check for the [AllowResizable] WebIDL
extended attribute.
Bug: v8:11111
Change-Id: Ie7e03979ef3884123df8a3eeb5c3516c4a6967c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4082276
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84715}
With this CL, the context of stacks corresponding to all client isolates
are saved, so that conservative stack scanning can be used correctly
during a shared garbage collection. This happens:
1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
isolate and the initiator;
2) when an isolate's main thread is waiting in a safepoint; and
3) when an isolate's main thread is parked.
Bug: v8:13257
Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84712}
Promoted pages are iterated to record slots containing old to new and
old to shared references. This takes a significant amount of time during
the atomic pause.
Instead we offload this task to the concurrent sweepers, record slots to
a local cache, and merge it when finalizing sweeping.
Array buffer sweeping depends on iteration of promoted pages, so it is
frozen until iteration is done.
See design doc at https://docs.google.com/document/d/1JzXZHguAnNAZUfS7kLeaPVXFfCYbf5bGCtyKgyiMDH4/edit?usp=sharing
Bug: v8:12612
Change-Id: Icdc79a7a70c53352e3a1b3961cfe369e8563b65b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062041
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84706}
Adds new `br_on_cast null <branch depth> <heap type>` instruction
with opcode 0xfb4a.
The instruction branches on null.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: I0f1debacc80a304f7cfc262fd2cde7f43fc804d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075086
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84703}
It turned out that executing 1 million (wasm) instructions can take way
over a minute on a simulator.
Thus changing this back to 16k instructions (as it was before
https://crrev.com/c/4078983). This takes around 5 seconds on my machine.
R=jkummerow@chromium.org
Bug: chromium:1396351, chromium:1396237
Change-Id: Ibf2ae2c81816be93807e564876b75aec18a57c42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079195
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84691}
The zone should just be a member of {WasmModule} instead of a
heap-allocated second object.
R=ahaas@chromium.org
Change-Id: I9cf7d5145ea9131a5ae3382c6f5aa63b816d9aa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080032
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84690}
This is a reland of commit eeed2ebadb
Changes since revert:
- Disable test for builds that don't support shared heap.
Original change's description:
> [heap] Invoke GC callbacks in safepoint for shared GCs
>
> After a shared GC, trigger all registered callbacks while the global
> safepoint is active.
>
> Bug: chromium:1395117
> Change-Id: I16c61533d44fbeddda18414d2256203848420a99
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84653}
Bug: chromium:1395117
Change-Id: I145dadac39d81342d7fbc2bad8b87f3518b0100e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081130
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84687}
... so that we can check that we correctly installed a maglev
code during OSR.
Bug: v8:7700
Change-Id: I6f1d12e8b43cb7c0639e75c43400c5000c090a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078937
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84686}
Shared heap is not available without write barriers, therefore skip all
tests that require shared heap when write barriers are disabled.
Change-Id: I66a9a94941ffab792ced964f12df6930b13c92cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079120
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84682}
This reverts part of crrev.com/c/4020425, because it turns out that the
runtime call pays off for strings above a certain length.
Bug: v8:12868
Change-Id: I1c4d5a01bb0f1303c2385c7707b3e5fff6936b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075728
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84668}
This reverts commit 7b138dd30d.
Reason for revert: Causes multiple flakes:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22932/overviewhttps://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/41934/overview
Original change's description:
> [wasm] Compile debug code lazily
>
> Currently V8 recompiles all functions of a WebAssembly module when a
> debugging session starts. This is outdated behavior and
> causes OOMs for developers. With this CL all compiled code just gets
> removed when a debugging session starts, and debugging code gets
> compiled lazily.
>
> This behavior may lead to small delays whenever a new function gets
> entered by the debugger. However, developers are used to debugging code
> being slightly slower, and the small delays should be in the order of
> few milliseconds. On the other hand, debug modules can be big,
> sometimes even more than 1'000'000 functions, and developers reported
> OOMs when debugging.
>
> R=clemensb@chromium.org
>
> Bug: v8:13541, chromium:1372621, v8:13224
> Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84662}
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ic5442462d158618f2d43b8e0ebdfb90017ed378a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080034
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84665}
Currently V8 recompiles all functions of a WebAssembly module when a
debugging session starts. This is outdated behavior and
causes OOMs for developers. With this CL all compiled code just gets
removed when a debugging session starts, and debugging code gets
compiled lazily.
This behavior may lead to small delays whenever a new function gets
entered by the debugger. However, developers are used to debugging code
being slightly slower, and the small delays should be in the order of
few milliseconds. On the other hand, debug modules can be big,
sometimes even more than 1'000'000 functions, and developers reported
OOMs when debugging.
R=clemensb@chromium.org
Bug: v8:13541, chromium:1372621, v8:13224
Change-Id: Ia36d9b8743523b1c89221c59f989268e27f6ce98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067302
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84662}
By applying the same special-case that the Torque builtin already has
to the runtime function.
This is a quick fix pending discussion what the right long-term solution
should be.
Bug: v8:13523
Change-Id: I5303d5ac598d00189f7eb2d9d78b81ad11b919b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075527
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84654}
After a shared GC, trigger all registered callbacks while the global
safepoint is active.
Bug: chromium:1395117
Change-Id: I16c61533d44fbeddda18414d2256203848420a99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84653}
This is a reland of commit bb288ea342
Changes since revert:
- Skip added test in single generation builds (shared heap is not supported in single generation).
- Use Isolate::Current() instead of GetIsolateFromWritableObject() for strings that reside in shared space (not only if the string is actually shared).
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I6889b565f8a247ae1fe553158e29984e7c05563a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079224
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84652}
The OnProfileEndListener callback has to be reset before the isolate
dies to avoid a use-after-free when the Global which holds the callback
gets released.
Drive-by change: make the OnProfileEndListener callback
isolate-specific. At the moment a `profileEnd` call in IsolateA could
trigger the OnProfileEndListener callback of IsolateB, which could
cause all kinds of data races (the callback would access the isolate,
but the isolate is not supposed to get accessed by multiple threads
concurrently. With this CL there is one callback per isolate.
R=clemensb@chromium.org
Bug: chromium:1395237
Change-Id: Ifaa5b883a231f5519a3bfeb6187fb7d8faa02b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076465
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84646}
The fuzzers based on {WasmExecutionFuzzer} (wasm-code, wasm-compile)
were already switched over in https://crrev.com/c/4042288.
The wasm-async and wasm fuzzers were still testing against the
interpreter, even though WasmGC opcodes are enabled, which leads to
crashes due to incomplete interpreter support.
This CL now switches those remaining fuzzers to "liftoff as reference"
mode, and removes support for testing against the interpreter.
As Liftoff code runs a lot faster than the interpreter, we bump the
limit for the number of executed instructions from 16k to 1M.
R=jkummerow@chromium.org
Bug: chromium:1387316, chromium:1393379, v8:13496
Change-Id: Id3e6177cc89b49e69d03515f10eedaf0872bde82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078983
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84644}
For some reason, {OwnedVector} defines both a {start()} and a {begin()}
accessor which return the same value. As {begin()} is the name that the
standard library uses, this CL removes {start()} and switches all uses
to {begin()}.
R=mslekova@chromium.org
Change-Id: Ib505fe146db396f7589404c5a630e19248624729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075865
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84643}
The wasm export wrapper passes the expected type as a Smi parameter to
the {WasmJSToWasmObject} runtime function. However, since this wrapper
might be compiled by a different module that is currently running it,
it is not enough to pass the module-specific type index and the module
to reconstruct the type. Rather, we must pass the canonical type
index.
Bug: v8:7748
Change-Id: I84e34e855898477a135f213f07bca10e95ecf49a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068123
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84641}
