If an output operand has "same as input" policy, we cannot assume that
it's input 0. Instead we should look at the {input_index}.
The bug manifests on Wasm select instructions, where the input index is
actually 2 and not 0.
In order to test this better, we introduce the a new
--turbo-force-mid-tier-regalloc flag, which always uses the mid-tier
register allocator. Otherwise the bug would only manifest on huge
functions.
R=mslekova@chromium.org
CC=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I6a005a48bbd2aba354dc99fed587bffce24c8839
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234722
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77495}
Comments in interface-descriptors stated that the argument count is
without the receiver, which is no longer true (see [1]).
[1] https://crrev.com/c/3140608
Bug: v8:11112
Change-Id: I75277bd4044a49a5a668f602501ad229bc44720b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234491
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77494}
Calling class constructors without new is a spec violation and should
raise an exception.
In [1] calling class constructors with spread (without new) was handled
by reducing the node to a call to runtime to raise the exception.
However, arguments of the call have to be evaluated first ([2]).
This CL changes the reduction of JSCallWithSpread/JSCallWithArrayLike to
a no-op in JSCallReducer if the target is a class constructor, delaying
raising of the exception to the call builtin.
[1] https://crrev.com/c/3229369
[2] https://tc39.es/ecma262/#sec-evaluatecall
Bug: chromium:1262007
Change-Id: I2ef504d4ce6e51d582b5951beb6debb983cefba6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236348
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77492}
This CL exposes the async stack traces instrumentation on the console
object, behind a --experimental-async-stack-tagging-api flag. It serves
as a prototype that aims to validate whether the debugging experience
can be improved for userland code that uses custom schedulers. The tests
are implemented as Blink web tests in the following CL:
https://chromium-review.googlesource.com/c/chromium/src/+/3226418
Bug: chromium:332624
Change-Id: Ib1ee71de68f7bb9aff5b944812ce681d8711d217
Signed-off-by: Victor Porof <victorporof@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212506
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77491}
We use a mutex to avoid data race when reading/writing to the
code object registry.
Functions called only by the sweeper happens during safepoints and
do not need to be protected by the mutex.
Bug: v8:12054
Change-Id: Ie85bf0422622eee7f2836ecae132397a6aa4ed59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234721
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77490}
Rolling this manually because we have to update paths in sync with
instrumented_libraries due to https://crrev.com/c/3224627.
Rolling v8/third_party/instrumented_libraries:
6527a4e..3c149f5
Bug: chromium:1261909
Change-Id: Ibcb6ebefa287e0125e0cb75be8dc51dea392a502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233138
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77489}
This is a reland of 6cd14492aa
Additionally rolls buildtools to include https://crrev.com/c/3045960
Rolling v8/build: f78b0bd..110f470
Rolling v8/buildtools: a9bc3e2..f5750f5
Original change's description:
> [Fuchsia] Remove checkout_fuchsia_for_arm64_host
>
> Also roll /build to a version that contains the cl removing
> checkout_fuchsia_for_arm64_host
>
> Bug: chromium:1137662
> Change-Id: I72851e5ab4e1daabf6ea62fb7935dfd28d8dee25
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3232816
> Auto-Submit: Chong Gu <chonggu@google.com>
> Commit-Queue: Chong Gu <chonggu@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77486}
Bug: chromium:1137662
Change-Id: Iaa142fd3e61ce14972381f309a83f45e1a0cb318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236347
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77488}
Also roll /build to a version that contains the cl removing
checkout_fuchsia_for_arm64_host
Bug: chromium:1137662
Change-Id: I72851e5ab4e1daabf6ea62fb7935dfd28d8dee25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3232816
Auto-Submit: Chong Gu <chonggu@google.com>
Commit-Queue: Chong Gu <chonggu@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77486}
Port 8bbb44e537
Port 7c08633bf6
Change-Id: Iebc3e223a0a7bc5f31ef0f21d8589e60ccdc0833
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233695
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77485}
Relaxed f32x4 and f64x2 min and max.
These instructions only guarantee results when the inputs are non nans,
and when the inputs are not 0s of opposite signs.
Reuse existing float binop testing harnesses and add special checks for
such constants when relaxed operations are being tested.
Drive-by rename of x64 instruction codes to be Minps/Maxps/Minpd/Maxpd
since they map down exactly to a single instruction.
Bug: v8:12284
Change-Id: I1449dbfa87935a96d7d260db22667ab7b9e86601
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218196
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77484}
--no-stress-flush-bytecode doesn't exist and should be
--no-stress-flush-code. Not supressing it means a tester could pass
--stress-flush-code and --no-flush-bytecode, which are contradictory and
will assert.
Bug: v8:12331
Cq-Include-Trybots: luci.v8.try:v8_numfuzz_dbg_ng,v8_numfuzz_ng
Change-Id: I6490271bcb11f5ea925eb8b65fbe0455c2dafeaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77483}
Port e127f58410
Original Commit Message:
Handling of class constructors was moved from CallFunction to Call
in [1].
When reducing calls with spread we forward varargs directly to
CallFunction, if we are spreading to inlined arguments or arguments of
the outermost function.
In that case we didn't check for class constructors and therefore didn't
raise an exception.
This CL adds checks for class constructors to all JSCall* nodes in
JSCallReducer that missed them before.
[1] https://crrev.com/c/3186434R=pthier@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I02cba90369354f064201daa1bf8812e17cb2dc21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234040
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77480}
... when the v8_enable_external_code_space build flag is enabled.
Bug: v8:11880
Change-Id: I754c6229dcd25f81ef6dfbedc5885ac025c0aeff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3164458
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77479}
The cctest enables concurrent-sparplug during startup, which creates
a job_handler_, then disables the flag before destroying the isolate,
which calls the destructor of ConcurrentBaselineCompiler.
This does not call job_handle_->Cancel and fails in a DCHECK inside
the default_job implementation.
Bug: v8:12054
Change-Id: I8975e2ad2c0aafaa86aedb13018617a08f0fded9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234718
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77475}
Port 8bbb44e537
Original Commit Message:
Large character classes may easily be created when unicode
properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
expanded internally into character classes that consist of hundreds
of character ranges. Previously to this CL, we'd emit branching code
for each of these ranges, leading to very large regexp code objects.
This CL adds a new codegen mode for large character classes (where
'large' currently means > 16 ranges). Instead of emitting branching
code inline, the ranges are written into a ByteArray and we call into
the C function IsCharacterInRangeArray for the actual branching logic.
The ByteArray is smaller than emitted code and is deduplicated if the
same character class is matched repeatedly in the same pattern.
Note this mode is *not* implemented for the interpreter, since we
currently don't have a constant pool for irregexp bytecode, and thus
cannot reference ByteArrays.
R=jgruber@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I2ded01fa2767e56e72be81b949eefb5fb85b7013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231981
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77473}
Handling of class constructors was moved from CallFunction to Call
in [1].
When reducing calls with spread we forward varargs directly to
CallFunction, if we are spreading to inlined arguments or arguments of
the outermost function.
In that case we didn't check for class constructors and therefore didn't
raise an exception.
This CL adds checks for class constructors to all JSCall* nodes in
JSCallReducer that missed them before.
[1] https://crrev.com/c/3186434
Bug: chromium:1260623
Change-Id: Id39cdfd09ff5aae804ae30d96909518e408c9613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229369
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77472}
These two tests rely on the functions being immediately compiled with SP.
Concurrent SP might add a delay and fail the test.
Bug: v8:12054
Change-Id: I52dbdfeb5c49c23f2d20a43bb8a87aba1f16358e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233233
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77471}
When --always-sparkplug, we compile on the main thread. This fixes the
CodeBuilder path when also running with --concurrent-sparkplug
Bug: v8:12054
Change-Id: Ifafcd68b635e99ca39c5eebc3e1ff839a2193eb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233232
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77470}
last_index_ is already incremented in Enqueue and points to one past
the end of the array.
Bug: v8:12054
Change-Id: I63b9a315464af9366f39c863fbd40e58adb69f1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233230
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77469}
Add a readonly --dict-property-const-tracking flag so that we can
correctly specify negative implications for --concurrent-inlining and
--turboprop, and correctly fail flag contradictions where needed.
Change-Id: I1b20c6a2bef42c868ccde3b8db60f1107eb29550
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233222
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77466}
Search for free memory ranges within the +/- 2GB boundary to the
embedded builtins. So that code range can be allocated close to the
binary to enable short builtin calls when pointer compression is
disabled.
Bug: v8:12045, v8:11527
Change-Id: I4698625882c3c7c39aff73b0bc874ddcfc990881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212466
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77465}
Large character classes may easily be created when unicode
properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
expanded internally into character classes that consist of hundreds
of character ranges. Previously to this CL, we'd emit branching code
for each of these ranges, leading to very large regexp code objects.
This CL adds a new codegen mode for large character classes (where
'large' currently means > 16 ranges). Instead of emitting branching
code inline, the ranges are written into a ByteArray and we call into
the C function IsCharacterInRangeArray for the actual branching logic.
The ByteArray is smaller than emitted code and is deduplicated if the
same character class is matched repeatedly in the same pattern.
Note this mode is *not* implemented for the interpreter, since we
currently don't have a constant pool for irregexp bytecode, and thus
cannot reference ByteArrays.
Bug: v8:11069
Change-Id: I2d728e42d85114b796c637f791848731a104cd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77463}
Huge functions can take a really long time (several minutes) in register
allocation. This is caused by a big number of virtual registers combined
with a big number of blocks.
We can avoid such long-running register allocation by falling back to
the mid-tier register allocation if we detect a huge number of virtual
registers.
Note that this is mostly relevant for bigger WebAssembly modules, but we
implement it as a general TurboFan flag.
The flag is off by default for now, since there seem to be bugs lurking
in the mid-tier register allocator. Once those are fixed, we can stage
it behind --future and then ship it.
R=mslekova@chromium.orgCC=thibaudm@chromium.org
Bug: v8:12320
Change-Id: Iff14de456c2b3a91ee2b2b12221295dd56b69463
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231336
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77461}
mjsunit/regress/regress-crbug-9161 had two spinlocks on an atomic:
1. WaitUntil(lock == kStageRunning)
2. WaitUntil(lock == kStageDone)
But, in theory the worker updating the "lock" could progress all the way
to kStageDone before the first loop manages to check the lock value
again.
We can make this more robust by checking:
1. WaitUntil(lock != kStageInit)
2. WaitUntil(lock == kStageDone)
That way both loops check for _any_ state past the state they want to
progress past.
Bug: v8:11437
Change-Id: I5220e61070a305301c678928edb0925c04dae970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231339
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77460}
... by explicitly passing pointer compression cage base value to various
IsXXX() and map() calls in order to avoid using incorrect auto-computed
cage base value when applied to objects allocated in external code space.
This CL also introduces IsCodeObject(HeapObject) predicate which checks
the IS_EXECUTABLE bit in the page header's flags.
Bug: v8:11880
Change-Id: Ib44398c3125392e46e939044a9bd27e09d7944d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229368
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77459}
This CL adds support for BigInt.asIntN, the necessary operations and
extensions of the compiler's type system to allow lowering of BigInts
to word64 representations that are interpreted as signed 64 bit BigInts.
Bug: v8:9407
Change-Id: Id4f1f45437c1caf94e01c7b4e063c2ae2386c88a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3198070
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77458}
We increment the size before enqueueing the next element.
This guarantees that size > 0 when decrementing.
Bug: v8:12325
Change-Id: Ida256d9b22a9dd5cacb21312f099ee7186e2ca53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231335
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77457}
A few of the changes added by https://crrev.com/c/3229379 are
causing compilation errors on platforms without sparkplug.
Change-Id: Ic6088b33ba910ae5a96881fa7609e30d35db5d8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226548
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77456}
Disable --concurrent-inlining when v8_dict_property_const_tracking is
enabled, since the latter doesn't support the former. Add statusfile
variables to mark this as an incompatible flag, and otherwise disable it
via flags.
Change-Id: Ie2e7dac6f4a1ddc97e7e7f4d4d2c77e638e216a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229565
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77455}
Previously having a `Symbol.toStringTag` property holding a string
somewhere in the prototype chain would always take predence over trying
to determine a reasonable name from the "constructor" (in case of
subclassing). This would lead to confusing behavior when diagnosing
objects in DevTools, for example
```js
class A extends URLSearchParams {};
new A()
```
would show `URLSearchParam` as class name for the instance rather than
`A`.
With this CL, we change the lookup logic to explicitly check for
`Symbol.toStringTag` and "constructor" along each step of the prototype
chain (skipping the "constructor" for the leaf object) and pick the
first one that yields a string (that is the function debug name in case
of "constructor").
Fixed: chromium:980018
Change-Id: Ic920b4bae02f965bc383c711f8de89c0de55fcac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231078
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77453}
`a || b` only evaluates b if a is false. `a | b` always evaluates
both a and b. If a and b are of type bool, `||` is usually what you
want, so clang now warns on `|` where both arguments are of type bool.
In this case the difference isn't important, but || is more
conventional to express this
Bug: chromium:1255745
Change-Id: I8fb090abc9863f7db8761bddb1440613a49bc84b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231077
Auto-Submit: Hans Wennborg <hans@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77452}
This is a reland of 929b83fb7b
This version of the CL also fixes initialization of the
marking_barrier_ in the LocalHeap constructor.
This CL also got rebased on Victor's CL in https://crrev.com/c/3229361.
It added a code_space_allocator_ in LocalHeap which needs to be
initialized a bit later on the main thread as well.
Original change's description:
> [heap] Attach to shared isolate after setting up main thread
>
> Attach to the shared isolate after the main thread was set up. Otherwise
> it could happen that a shared GC initiated from another isolate might
> see no threads are running and performs the safepoint operation in the
> middle of isolate deserialization.
>
> We use DisallowSafepoints to check that the isolate doesn't join a
> global safepoint before deserialization is complete. DisallowSafepoints
> used to prevent only invocations of Safepoint() but was updated to
> also prevent Park() and Unpark() invocations. Each state change could
> cause the thread to reach a safepoint, which would allow a shared GC
> to run.
>
> We now also DCHECK that every isolate has at least one local heap and
> that shared collections aren't started before deserialization is
> complete.
>
> Bug: v8:11708
> Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77424}
Bug: v8:11708
Change-Id: I7d44e4a5f76cc09092c2444cede10e9331222c1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229361
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77448}
