This is a reland of c927ada76c
Fix: Recalculate encoding after an allocation (that can potentially
trigger GC) in EnsureHasFullTransitionArray.
Original change's description:
> [runtime] Refactor TransitionsAccessor
>
> Problems:
> - The class uses a bare Map field, but some methods can trigger GC
> causing it to have a potential dangling pointer in case of map
> compaction.
> - Some methods invalidate the object state and should not be used again.
> - Complicate logic with a no_gc and a gc aware constructors. Some
> methods can only be called if the object is constructed with a
> particular constructor (e.g, Insert and PutPrototypeTransition).
>
> Note: Most usages of this class is done by constructing an object and
> calling a single method:
> `TransitionAccessor(...).Method(...)`
> So we can easily change them to a static method.
>
> This CL:
> 1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
> 2. Makes methods that can trigger GC static.
> 3. Creates static helper functions that wrap the class in a different
> scope, since TransitionsAccessor now forces the scope to disallow gc.
> 4. Removes now unnecessary "Reload" logic.
>
> Bug: chromium:1295133, v8:12578
> Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79051}
Bug: chromium:1295133, v8:12578
Change-Id: If3880c2480433b78567870c8d14508d6ad9eccbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460405
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79069}
Previously, the accumulator was at the end of liveness bitvectors, which
meant that checking for accumulator liveness required a length lookup.
This CL moves it to the start of the bitvector, with registers starting
at index 1 -- the assumption is that the addition of 1 to the index on
register liveness access can be constant folded away.
As a cleanup, replace all the custom liveness printing code with a
single unified ToString. This places the accumulator at the end of the
printed liveness, to avoid having to change test expectations (also, the
position of the accumulator is now an implementation detail). As a
similar cleanup, change StateValue node building to use the
BytecodeLivenessState interface rather than the underlying bitvector.
These two cleanups allow us to remove the raw bitvector accessor from
liveness entirely.
Change-Id: Ic2744b5e8e16b8527e6a4e8d3b4ddad7096289d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455144
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79066}
Allows separating out the allocator from Heap without requiring a
heap.h include.
Drive-by:
- Rename "Retry" to "Failure".
- Avoid implicit constructors.
- Rename "RetrySpace" to "GarbageCollectionSpace" which is its only
use.
Bug: v8:12615
Change-Id: Idac17cded8f0b2b645a2be9045ab31ffd71999b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3456562
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79063}
We optimize trivial type checks in the function body decoder, i.e.,
ref.as_<type> and ref.is_<type> when invoked on a value that is
statically known to be of typeable as <type>.
Bug: v8:7748
Change-Id: Ieee608a965ba44c4cadd9c7171ed8bdc129fce8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3447375
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79061}
Changes:
- GenerateInitExpr should emit a function reference to a function that
is known to exist when funcref is expected.
- Add functions by signature index to the WasmModuleBuilder, so we avoid
signature canonicalization, which currently does not work for wasm-gc.
- Remove printing of recursive groups in the WasmModuleBuilder. Instead,
restrict type definitions to only refer to previous types.
- Some local restructuring of code, comments.
Bug: chromium:1296162
Change-Id: I5abd9bf8ec21ef6a51f00bc960b78519f2ec94f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3452433
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79054}
This changes the way how we are handling instrumentation breakpoints.
Motivation:
with instrumentation breakpoints, we need a way to break
on (conditional) breakpoints that were just set by the client on
the instrumentation pause.
How:
We want to first find out if we have an instrumentation break, and
trigger a pause. For this to work, we need to distinguish between
regular and instrumentation breakpoints in the debugger back-end.
On resume, we want to check if we have hit any breakpoints (may
now contain new breakpoints due to the client setting new breakpoints
at the previous instrumentation pause) and trigger a separate pause
for them.
Fixed: chromium:1292930
Change-Id: Idaadd276c44c693f856c4b08c7a72ea67271f420
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3442676
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79053}
This reverts commit c927ada76c.
Reason for revert: GC stress failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/37276/overview
Original change's description:
> [runtime] Refactor TransitionsAccessor
>
> Problems:
> - The class uses a bare Map field, but some methods can trigger GC
> causing it to have a potential dangling pointer in case of map
> compaction.
> - Some methods invalidate the object state and should not be used again.
> - Complicate logic with a no_gc and a gc aware constructors. Some
> methods can only be called if the object is constructed with a
> particular constructor (e.g, Insert and PutPrototypeTransition).
>
> Note: Most usages of this class is done by constructing an object and
> calling a single method:
> `TransitionAccessor(...).Method(...)`
> So we can easily change them to a static method.
>
> This CL:
> 1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
> 2. Makes methods that can trigger GC static.
> 3. Creates static helper functions that wrap the class in a different
> scope, since TransitionsAccessor now forces the scope to disallow gc.
> 4. Removes now unnecessary "Reload" logic.
>
> Bug: chromium:1295133, v8:12578
> Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79051}
Bug: chromium:1295133, v8:12578
Change-Id: Ia567cdcae73bc7fdfaf08b62eeeb899d6a933e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3456682
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79052}
Problems:
- The class uses a bare Map field, but some methods can trigger GC
causing it to have a potential dangling pointer in case of map
compaction.
- Some methods invalidate the object state and should not be used again.
- Complicate logic with a no_gc and a gc aware constructors. Some
methods can only be called if the object is constructed with a
particular constructor (e.g, Insert and PutPrototypeTransition).
Note: Most usages of this class is done by constructing an object and
calling a single method:
`TransitionAccessor(...).Method(...)`
So we can easily change them to a static method.
This CL:
1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
2. Makes methods that can trigger GC static.
3. Creates static helper functions that wrap the class in a different
scope, since TransitionsAccessor now forces the scope to disallow gc.
4. Removes now unnecessary "Reload" logic.
Bug: chromium:1295133, v8:12578
Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79051}
The flag has been turned on for a long time and we do not intend to
support a mode without young LO objects.
A side effect is that it removes a branch in AllocateRaw for the young
generation.
Drive-by: Reinstantiate the LO space verifier checking that only
certain types can appear as large objects.
Bug: v8:12615
Change-Id: I8c33019a04670f20459ea2faa9dc2f98b8cda40b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450420
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79044}
This CL fixes a bug in the tracing of full GC cycles that was introduced
by https://crrev.com/3432211. In doing so, it refactors the tracing of
cycles by introducing an explicit state in GC tracing events, which
follows the phase within the GC cycle as perceived by the tracer. Two
new methods, (Start|Stop)AtomicPause are introduced; together with
(Start|Stop)Cycle they mark the state transitions. The existing methods
(Start|Stop)ObservablePause are now disentangled from cycles and state
transitions.
Bug: v8:12503
Bug: chromium:1154636
Change-Id: Ie4b863bc27f81dd6858103a8988874d89e6e8517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3440663
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79043}
The build flag is on by default and the actual functionality is guarded
by a runtime flag.
Bug: v8:12612
Change-Id: I6adbd5b766f502400af32eeeb035edca3a3606ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3448383
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79036}
Handle the case of nested super() by checking if the class scope
contains a private brand. In this case the ContextScope chain
is different from the actual context chain so this added back
the AddPrivateBrand() runtime function but with the additional
step of walking the context chain to get the correct class
context that will be stored as the value of the brand property
for the debugger.
Bug: v8:12354
Change-Id: Ieeb9b9d6372bfbb1a39c4c2dc9e9848e9109f02a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275137
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79032}
NaN detection is implemented on arm and arm64, so we can enable fuzzing
with Liftoff as the reference implementation on these architectures.
R=manoskouk@chromium.org
Bug: v8:11856, v8:11954
Change-Id: If80c2f16f52af59705d914396cfe029cb85e7293
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3451718
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79031}
This is a reland of 4b8f1b1cff
After landing https://crrev.com/c/3447371, we can reland this CL as-is
correctness-wise.
What's new in this CL is that we now treat references from client
objects into the shared heap as roots for the --track-retaining-path
feature.
Original change's description:
> Reland "[heap] Support client-to-shared refs in Code objects"
>
> This is a reland of 12e46091a0
>
> Original change's description:
> > [heap] Support client-to-shared refs in Code objects
> >
> > Support references from code objects in the client heaps to shared heap objects. Such references are stored in a remembered set during marking, which is later used for updating pointers.
> >
> > Bug: v8:11708
> > Change-Id: I8aeb508ddd14514ca65fa5acf3030dd8c2040168
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401588
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#78819}
>
> Bug: v8:11708
> Change-Id: I47bcf44b452fcffe8675fba03244b736ede14247
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422630
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78838}
Bug: v8:11708
Change-Id: I5b48e942fa469eabb40e797e221d06c25af16443
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3425358
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79023}
--shared-string-table assumes that all old strings are in the shared
heap. However, when also using --expose-gc we create an external string
for the GC function name. So far external strings are always allocated
in the local old space though, which results in a heap verification
error. This CL creates external string in the shared old heap with
--shared-string-table enabled.
In order to pass all the tests this CL also has to:
* Stop marking into the shared heap for VisitEmbeddedPointer and
VisitCodePointer.
* Relax DCHECK in String::GetFlatContent: We cannot check the thread
id for any shared string. Even if that string isn't really shared atm.
Bug: v8:11708
Change-Id: I51fec5ba038d035be5fe5e1277ef9286efc8dc2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3447371
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79022}
As a temporary solution to reenable wasm-gc fuzzing, we modify
{WasmModuleBuilder} to optionally wrap all types in a recursive group.
Bug: v8:7748
Change-Id: Ib0f8ab17c48ecbe04b51da2b1d01502be77ad35a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450414
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79015}
Drive-by: Change the macro magic around elements kind runtime predicates
to make the function names grep-able.
Fixed: v8:10105
Change-Id: Id5046bd0e60f40611c6c264613729fb9c6b73853
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420306
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79005}
Not all environments (like ShadowRealm) would expect console
APIs to present in their globals. Moving console API to
context's extras binding to allow them to be still
snapshotted to not slow down the bootstrap.
The console API is not removed from the global in this CL,
but it is planned to be removed in the later release.
Bug: v8:11989
Change-Id: Ieca09e0bafdf8943e8fff8fee97fc21c2326320f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364786
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#78998}
The regexp parser historically has tried to gracefully detect and bail
out from excess zone allocations, where 'excess' was determined to be
an arbitrary limit of 256MB.
This leads to issues now that the regexp parser may run from within
the JS parser - the JS parser doesn't observe this arbitrary limit and
happily keeps allocating until the underlying allocator actually runs
out of memory; this way, the JS parser can handle very large JS files,
and it's now counterproductive if the regexp parser (which reuses the
JS parser zone) bails out on excess allocations.
This CL simply removes the excess_allocation mechanism.
Bug: chromium:1264014
Change-Id: I8d93a1e52aa65bb0ea6c2aab3b68b479ce79a1f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401580
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78991}
Previously the inspector was trying to handle step-out for async
functions by annotating the async stacks, but this was merely a
hack and didn't work reliably
(a) when the async caller that is `await`ing the result of the
callee was still in the synchronous part (because then there
was no async task yet in the inspector), or
(b) not at all when the async stack tracking wasn't enabled or the
maximum async stack depth was too small.
This CL replaces that hack with a pragmatic solution inside the
V8 debugger, where upon `await` we memorize the async function
object of the caller on the outer promise of the callee, and when
stepping out of the callee we check whether the returned promise
has a memorized async function object and if so, we schedule that
to resume.
This CL thereby effectively reverts https://crrev.com/c/1054618
and replaces it with a V8 debug solution, and thereby further
reduces the (memory) overhead of an AsyncStackTrace.
Fixed: chromium:1246867
Bug: v8:6161, v8:7753, chromium:1277451, chromium:1280519
Change-Id: I6aa79e90f49d204f66bfd37e7a328c7fb8d635b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439865
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78990}
Properly push back the current request promise for async generators when
resuming after an `await` to ensure that the catch prediction works as
expected for async generators.
Fixed: chromium:1220203
Change-Id: I8c3592ceb567aadcba8f460794cd5d60a965a360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3442680
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78984}
After https://crrev.com/c/3416191 there are too many mixed concerns in
the clusterfuzz directory. We split it into js-fuzzer, foozzie and
trials.
Change-Id: I9a21ee83985e6113d77acba4583e99df88723c60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3443505
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78981}
Currently, the stack-switching import wrapper always suspends. Only
suspend if the returned value is a promise, otherwise just convert and
return the value back to wasm.
R=ahaas@chromium.orgCC=fgm@chromium.org
Bug: v8:12191
Change-Id: I26e7a3921aeae30fcce7f0ccc98d790a1a6f8c35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3440655
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78980}
Make it include the invalid length again, but this time consistently.
Bug: chromium:923688
Change-Id: I0ec2543e02b58ff2b79547021a8e0d47a9debe46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3440068
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78976}
We introduce a new information type ForwardingIndex to be stored in
the Name::Hash field (to be used in the future).
To do so we use the 2 least significant bit to distinguish types
of information stored in the hash field (in contrast to only bit 1
to distinguis integer indicies from "real" hashes).
This motivated a refactor to use base::BitField for the hash field.
Bug: v8:12007
Change-Id: I651c86807edfc218792d0db12379374eaa50c930
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432385
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78975}
This is the final step towards moving away from sending `url` with
every call frame when emitting the `Debugger.paused` event.
Fixed: chromium:1270316
Bug: chromium:1271078
Change-Id: I87a286d81eb91a9bed64213c4b18db0675858822
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345001
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78974}
- Suspender.suspendOnReturnedPromise expects a function with type
[ti*]->[externref] and returns a function with the same type.
- Suspender.returnPromiseOnSuspend expects a function with type
[ti*]->[to] and returns a function with type [ti*]->[externref].
Changes:
- Check the wrapped function's return types
- Skip type checking of return types when importing a wrapper (and
assert that the return type is externref)
- Add special case for WebAssembly.Function.type of a
WasmExportedFunction: it currently returns the signature declared by
the module. Change the return type to externref if this is a
stack-switching export.
Bug: v8:12191
Change-Id: I6619c306e9613825ad1b021cb3400d73cd684656
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435190
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78973}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I428d21f5e6a9c51c8c7c4577395bf27c8706bdb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3441033
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78963}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I52d5a172ea602f4ad058d979003d51a80cdb4405
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3441022
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78961}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I4d2c9f5d4d7bc50b3aeb515eb78c08eb1b2a6824
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3440902
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78960}
Replacement is v8::TracedReference in combination with v8::Global if a
callback is really needed.
Bug: v8:12603
Change-Id: Iae48fee2e6588a594d430c5f3a71ff0b3e67e5b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439873
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78950}
TracedNode is used as backing node for v8::TracedGlobal (with
destructor) and v8::TracedReference (no destructor).
A future change adds concurrent marking for TracedReference which
requires that the node stays around until the atomic pause to avoid
synchronization with the concurrent marker.
This change prepares TracedNode in prolonging the lifetime until the
it is actively cleared ("sweeped") in the atomic pause. This allows
for spuriously keeping alive a TracedNode for an additional GC cycle
in the case the the node was destroyed while the marker is running.
We maintain eager clearing of nodes where possible, i.e., outside of
incremental marking.
Bug: v8:12600
Change-Id: I9688c83a42b70d352c84613485f37242b1b910a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3436805
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78947}
TimeTicks::HighResolutionNow is identical to TimeTicks::Now since 2018
(https://crrev.com/c/997153), but the declaration still has a wrong
comment about a non-existing DCHECK.
In order to avoid confusion, remove the redundant method and just use
TimeTicks::Now everywhere.
Drive-by: Make IsHighResolutionTimer "inline" instead of "V8_INLINE"
because it will only be called once anyway.
R=mlippautz@chromium.org
Bug: v8:12425
Change-Id: I31dc65f8c1ac910862e070e60e928054d4921154
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439909
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78944}
This is a reland of 517ed4ad00
Original change's description:
> Reland "[Torque] Generalize Torque literals to larger size"
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Changes in the reland: Simplified IntegerLiteral to single digit.
>
> Bug: v8:7793, chromium:1289282
> Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78811}
Bug: v8:7793, chromium:1289282
Change-Id: I7aadc4d2c9494f03eae85e94949c8f4cab7a075c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3437047
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78939}
The stack guard may update a shared memory's size. Therefore, we need to
update the size in the instance cache in Turbofan when StackCheck is
invoked for loops.
Change-Id: I1b000adad991a6b799ad37ba36c9a33c67559d3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423780
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78925}
This is a reland of f942f656dc
Changes: Change the order of initialization for wasm continuations to
ensure object integrity if a GC happens during allocation. Also add
missing handles.
Original change's description:
> Reland "[wasm] Resume suspender on resolved promise"
>
> This is a reland of a865d16bc2
>
> Changes:
> - Make the next ID atomic
> - Leave more space for runtime calls in debug mode
>
> Original change's description:
> > [wasm] Resume suspender on resolved promise
> >
> > Implement the WasmResume builtin, which resumes a wasm suspender
> > when the corresponding JS promise resolves.
> >
> > Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
> > Drive-by 2: Add a stack ID for better tracing.
> >
> > R=ahaas@chromium.org
> > CC=fgm@chromium.org
> >
> > Bug: v8:12191
> > Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#78842}
>
> Bug: v8:12191
> Change-Id: I3c231690b27be79a0c00e13043342bb4a3628886
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427203
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78890}
Bug: v8:12191
Change-Id: I0e1362d3a9da1fd8c0d600ad9776ce2fd26c6a52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3434145
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78922}
The methods in explicit_management.h should be called via the public
variants in the subtle namespace. Calling the variants in the internal
namespace directly skips asserts and required size coversions. Doing so
may cause misuse of the api that may break GC inernals
Change-Id: I58a0f324ca1ee0839bb85eb9b53ce57785dc7b91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435187
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78920}
- Heap-stats was trying to load the map without explicitly passing in
the PtrComprBase causing failures with Code objects in external code
space
- Extend the debugPrint.js tests to run with some more debugging and
testing flags to prevent future regressions
Change-Id: I1f0d03cb31480f316fe533b507ff98fe3befbe8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432386
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78919}
This makes the bulk memory operations respect the memory type, i.e.
using i64 values for memory offsets if memory64 is enabled.
The called C functions now expect memory offsets to be passed as
{uintptr_t}, such that we can address any memory on all systems. For
64-bit memories on 32-bit systems, the upper half of the 64-bit value is
checked in compiled code before passing the lower half to the C
function.
Liftoff support turned out to be a bit harder than expected, because we
cannot hold three 64-bit values in registers on ia32 (not enough
registers...). Thus implement that in a follow-up CL.
R=thibaudm@chromium.org
Bug: v8:10949, chromium:1281995
Change-Id: Ie77636145f94cc579d479c4e7c346ba3c682679d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427206
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78918}
This CL adds invalidations for slots that reside in promptly freed or
shrunk storage.
Bug: chromium:1029379
Change-Id: I05e0ede55c202c952b26f452053b8777d1a2ffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431488
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78912}
Conceptually, a full GC cycle completes when the sweeping phase is
finished. As sweeping is performed concurrently, this happens after
Heap::CollectGarbage has returned and, at the latest, before the next
full GC cycle begins. However, an arbitrary number of young GC cycles
may happen in the meantime. Tracing information for the sweeping phase
must be added to the corresponding full GC cycle event. Until now, this
was not done correctly: this information was added to the GCTracer's
current event and could thus be attributed to a subsequent young or full
GC cycle.
This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
cycle (still allowing for full GC cycles to be interrupted by young GC
cycles). These methods are different from (Start|Stop)ObservablePause,
which delimit the observable pause of each GC. The events of "pending"
full GC cycles are kept until they are properly amended and reported,
when the sweeping phase is finished.
This is a reland of 4ad20bff97
which was reviewed here: https://crrev.com/3404733
Bug: v8:12503
Bug: chromium:1154636
Change-Id: Icc315b53cff1f3b19b8efe49db34340a5608bcd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432211
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78911}
This reverts commit 4ad20bff97.
Reason for revert: New test seems to be failing on TSAN/incremental marking stress (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6346/overview)
Original change's description:
> heap: Fix the tracing of GC cycles
>
> Conceptually, a full GC cycle completes when the sweeping phase is
> finished. As sweeping is performed concurrently, this happens after
> Heap::CollectGarbage has returned and, at the latest, before the next
> full GC cycle begins. However, an arbitrary number of young GC cycles
> may happen in the meantime. Tracing information for the sweeping phase
> must be added to the corresponding full GC cycle event. Until now, this
> was not done correctly: this information was added to the GCTracer's
> current event and could thus be attributed to a subsequent young or full
> GC cycle.
>
> This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
> cycle (still allowing for full GC cycles to be interrupted by young GC
> cycles). These methods are different from (Start|Stop)ObservablePause,
> which delimit the observable pause of each GC. The events of "pending"
> full GC cycles are kept until they are properly amended and reported,
> when the sweeping phase is finished.
>
> Bug: chromium:1154636
> Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78905}
Bug: chromium:1154636
Change-Id: Id6688cfe982f9d8159c66d715b7079782a371bed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431489
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78908}
This is the second step towards moving away from sending `url` with
every call frame when emitting the `Debugger.paused` event.
Bug: chromium:1270316, chromium:1271078
Change-Id: Ib4f996024b5200cded155bd8a564d01d36856400
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431485
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78906}
Conceptually, a full GC cycle completes when the sweeping phase is
finished. As sweeping is performed concurrently, this happens after
Heap::CollectGarbage has returned and, at the latest, before the next
full GC cycle begins. However, an arbitrary number of young GC cycles
may happen in the meantime. Tracing information for the sweeping phase
must be added to the corresponding full GC cycle event. Until now, this
was not done correctly: this information was added to the GCTracer's
current event and could thus be attributed to a subsequent young or full
GC cycle.
This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
cycle (still allowing for full GC cycles to be interrupted by young GC
cycles). These methods are different from (Start|Stop)ObservablePause,
which delimit the observable pause of each GC. The events of "pending"
full GC cycles are kept until they are properly amended and reported,
when the sweeping phase is finished.
Bug: chromium:1154636
Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78905}
The CL does following:
1) Makes sure young generation works and tests pass;
2) Provides CollectGarbageInYoungGenerationForTesting() that is needed
to support remaining tests in Blink;
3) Moved cppgc_enable_young_generation GN flag to v8.gni to refer to it
from Blink;
4) Bails out from marking TracedReferences in UnifiedHeapMarkingState;
5) Disables (temporarily) prompt freeing for young generation;
6) Fixes remembered set visitation for nullptr|kSentinel slots.
Bug: chromium:1029379
Change-Id: I5165fa22c8a0eaa708ef7a35a9978cb12e1cb13e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429202
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78901}
This is a reland of a865d16bc2
Changes:
- Make the next ID atomic
- Leave more space for runtime calls in debug mode
Original change's description:
> [wasm] Resume suspender on resolved promise
>
> Implement the WasmResume builtin, which resumes a wasm suspender
> when the corresponding JS promise resolves.
>
> Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
> Drive-by 2: Add a stack ID for better tracing.
>
> R=ahaas@chromium.org
> CC=fgm@chromium.org
>
> Bug: v8:12191
> Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78842}
Bug: v8:12191
Change-Id: I3c231690b27be79a0c00e13043342bb4a3628886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427203
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78890}
We temporarily disable fuzzing for wasm-gc until we update the fuzzer
to the isorecursive hybrid type system.
Bug: chromium:1291959
Change-Id: I2238c37bc49cbac2bf1c4085815a2283db982ab3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423782
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78869}
For backwards compatibility, we do not impose this restriction on
nominal modules.
Bug: v8:7748
Change-Id: I42c4dc824fc9824280527522b05fa3bf68c8929b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422638
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78868}
Previously we'd predict exceptions thrown in [[Reject]] handlers as
always caught (by PromiseRejectReactionJob), but that's not what is
actually specified in ECMAScript. The PromiseRejectReactionJob will turn
any exception thrown into a promise rejection just like we do in the
case of PromiseFulfillReactionJob, and so the catch prediction should
match that behavior.
Fixed: chromium:1290861
Change-Id: Id992708b009666da7c6bf1b6e3cf30752ca0a227
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423775
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78864}
This reverts commit 7f26cbd291.
Reason for revert: Issue 1292333: DCHECK failure in op->IsStackSlot() || op->IsFPStackSlot() in code-generator-x64.cc
Original change's description:
> [fastcall] Add Wasm entry for Fast API calls
>
> Allow Wasm to generate calls directly to Fast API C functions.
> This massively reduces the overhead of these calls (~300%).
> Currently options parameter is not supported.
>
> This is a reland of
> https://chromium-review.googlesource.com/c/v8/v8/+/3364356
> with a fix to a data race.
>
> Bug: chromium:1052746
> Change-Id: I8c1c255419496d03a94ec2b443329842469586d5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398394
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#78714}
Bug: chromium:1052746
Change-Id: Ieb3f6f836bd604b0e4c5801f082997831eb7ac26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3426610
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78861}
Since inheritance depth of every type is known in the isorecursive
hybrid type system, rtts with depth are removed. This enables
simplification of type checks in Liftoff and Turbofan, as well as
decoding of object allocation instructions.
Bug: v8:7748
Change-Id: I6b52579b584191d92644de1c6e805d9f054641d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422626
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78860}
They're failing due to Inf/NaN differences after the latest clang roll,
skipping for now to keep the tree green. A follow-up CL will likely want
to broaden the expectations for these tests to allow both Inf & NaN in
certain cases.
Bug: v8:12588
Change-Id: I8055b67077fc67cc65246a89a4b4949d8838829e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3425660
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Adam Klein <adamk@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78855}
Runtime_HasProperty already does the right thing; this CL is directing
more cases to it.
Bug: v8:12580
Change-Id: I16ae6099fa9781ecc663085e87a7fc59abd10d02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422639
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78850}
This reverts commit 517ed4ad00.
Reason for revert: There still seems to be an issue on V8 Win msvc related to this CL (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/20568/overview).
Original change's description:
> Reland "[Torque] Generalize Torque literals to larger size"
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Changes in the reland: Simplified IntegerLiteral to single digit.
>
> Bug: v8:7793, chromium:1289282
> Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78811}
Bug: v8:7793, chromium:1289282
Change-Id: I818cec9625fbd827a4a30088d8c8b759fb6c50d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424484
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78847}
Implement the WasmResume builtin, which resumes a wasm suspender
when the corresponding JS promise resolves.
Drive-by 1: Fix detection of empty stacks in the stack frame iterator.
Drive-by 2: Add a stack ID for better tracing.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ifa3f00c4259f802292b04d426c739e9b551f87b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420827
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78842}
This is a reland of 12e46091a0
Original change's description:
> [heap] Support client-to-shared refs in Code objects
>
> Support references from code objects in the client heaps to shared heap objects. Such references are stored in a remembered set during marking, which is later used for updating pointers.
>
> Bug: v8:11708
> Change-Id: I8aeb508ddd14514ca65fa5acf3030dd8c2040168
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401588
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78819}
Bug: v8:11708
Change-Id: I47bcf44b452fcffe8675fba03244b736ede14247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422630
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78838}
We can avoid a pointer deref if the ValueSerializer is inlined in
WebSnapshotDeserializer.
Bug: v8:11525
Change-Id: I92d8cac37af3fdbe04a66465f97761bf5a9fd705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417433
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78830}
With dynamic tiering, the total amount of code generated for a
WebAssembly module decreases significantly. However, the amount of
code space we reserved for generated code has not been adjusted yet.
This CL adds a parameter for dynamic tiering to
EstimateNativeModuleCodeSize. If dynamic tiering is used, then the code
space reserved for TurboFan gets reduced to a quarter of the code space
without dynamic tiering.
Reserving a quarter of the space seems to be still quite generous. Even
Google Earth, seems to use a lot of its code, only needs less than 20%.
R=clemensb@chromium.org
Bug: chromium:1285334
Change-Id: I7dce0821b5e46d7240dfb1523031de84b1fe1348
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420307
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78826}
Drive-by fix to align what builds the test runner considers to be able
to have shared memory features and what builds can create a shared
Isolate.
Bug: v8:12007
Change-Id: I151513ccbfbee31e5b35c5ce8e9192732eabfee2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3421507
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78824}
This reverts commit 12e46091a0.
Reason for revert: new test fails on GC stress bot:
https://cr-buildbucket.appspot.com/build/8823858142855002833
Original change's description:
> [heap] Support client-to-shared refs in Code objects
>
> Support references from code objects in the client heaps to shared heap objects. Such references are stored in a remembered set during marking, which is later used for updating pointers.
>
> Bug: v8:11708
> Change-Id: I8aeb508ddd14514ca65fa5acf3030dd8c2040168
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401588
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78819}
Bug: v8:11708
Change-Id: If8d15a22651f8b1cfca61be21a81f60b43f008a4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3421725
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78821}
Support references from code objects in the client heaps to shared heap objects. Such references are stored in a remembered set during marking, which is later used for updating pointers.
Bug: v8:11708
Change-Id: I8aeb508ddd14514ca65fa5acf3030dd8c2040168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401588
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78819}
- It changes ContextSlotIndex from static to non-static.
- Updates ContextSlotIndex and ScriptContextTable::Lookup to use
handles, since it is necessary for the NameToIndexHashTable::Add
- Adds a NameToIndexHashTableLookup to CSA.
- Renames LocalNamesIterator to LocalNamesRange and iterates the
hashtable when local names are not inlined.
Bug: v8:12315
Change-Id: I2c8c933002fe73f4def145bc207825823262d743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406751
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78818}
This CL replaces the equirecursive type system for wasm-gc with the
isorecursive hybrid type system presented here:
https://github.com/WebAssembly/gc/issues/257.
In broad strokes, this includes the following changes:
- In the module decoder, remove equirecursive types. Implement recursive
type groups, subtype definitions, and function/struct/array
definitions. Treat nominal modules as syntactic sugar of an
isorecursive module, where all types belong in the same recursive
group.
- Remove rtt.sub and all related infrastructure.
- Change subtyping to work with explicit supertypes only.
- Add ValidSubtypeDefinition in subtyping, to check that subtype
declarations are valid during decoding.
- Remove the subtyping cache.
- Add support for functions to have specific signature index in
WasmModuleBuilder and in test-gc.cc.
- Adapt tests.
Current restrictions:
- Recursive groups are not stored beyond decoding.
- Type canonicalization is not implemented. No tests relying on types
being considered identical post-canonicalization.
- No cross-module subtyping is possible. Tests relying on cross-module
subtyping have been commented out.
Bug: v8:7748
Change-Id: I69fd04ecc5611f6230c95d5c89d1c520163fffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416239
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78816}
Changes:
- Introduce {TypeDefinition} for wasm modules.
- Introduce an enum {TypeDefinition::Kind} to represent the three
different definition types.
- Collapse the {types}, {type_kinds} and {supertypes} vectors into a
single vector of {TypeDefinition}s.
- Use {TypeDefinition} in WasmModuleBuilder.
- Drive-by: Remove {kNullIndex} in WasmModuleBuilder.
- Drive-by: Tidy-up wasm-module.h.
Change-Id: I97c2c268bcad745176243c693cf169bfa5714f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416233
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78813}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Changes in the reland: Simplified IntegerLiteral to single digit.
Bug: v8:7793, chromium:1289282
Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78811}
This CL replaces 'InvalidArgument' with 'ServerError' for
Runtime#getExceptionDetails. The reason is that the error we
raise is on the application level, allowing the DevTools frontend
to handle it to a certain degree. 'InvalidArgument' errors would be
interpreted as "something went really wrong", which is not the case
here.
Bug: chromium:1280141
Change-Id: Id72f06ce8daa06875adeb2528638a80ae61d9e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420304
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78809}
The functionality is unused and we are simplifying OptimizationMarker
usage.
Drive-by: Remove unused return value of Compiler::CompileOptimized.
Drive-by: Don't add kStackSpaceRequiredForCompilation as gap to the
stack check when compiling concurrently, i.e. on another thread.
Bug: chromium:757467
Change-Id: Ibbe204b82bf937b9eb74f9eb2c3fd2d719d53ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416245
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78800}
This is a reland of 5320fe8d58
Changes since revert:
- Remove stale DCHECK in deserializer
Original change's description:
> Reland "[string] Support shared strings in Value{Serializer,Deserializer}"
>
> This is a reland of 3cb4039cd1
>
> Changes since revert:
> - Fix FLAG_stress_scavenge interaction with shared Isolate
> - Use the shared Isolate's global handles to keep shared values
> alive in transit during a postMessage
>
> Original change's description:
> > [string] Support shared strings in Value{Serializer,Deserializer}
> >
> > When FLAG_shared_string_table is true, postMessaging strings will share
> > instead of copy.
> >
> > Note that not all operations on shared strings are supported, and shared
> > strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I70782978ed05558615eca03bafc4c12eba3644ca
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417189
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78791}
Create and return the chained promise, which resumes the suspended wasm
continuation once the JS promise resolves:
- Add stub for the WasmResume builtin, which will resume the given
suspender.
- Add the JS function wrapper for the builtin.
- On suspension, return promise.then(onFulfilled) to the prompt.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I2d6136b2bd610daa4be1880f347b7bdf897e75ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404776
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78787}
When reparsing the class scope to collect initializers in sloppy mode,
the class scope may still have a scope info without any allocated
variables. If its outer scope doesn't have an outer scope (which means
the outer scope in the optimized scope chain becomes the script scope),
we should also set the scope info in the script scope as is done
in Scope::DeserializeScopeChain() for the scope resolution.
Bug: chromium:1290587, v8:10704
Change-Id: I7804d53f330e59d4ab0405a11b132569f348b55d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3413647
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78784}
This is a reland of 3cb4039cd1
Changes since revert:
- Fix FLAG_stress_scavenge interaction with shared Isolate
- Use the shared Isolate's global handles to keep shared values
alive in transit during a postMessage
Original change's description:
> [string] Support shared strings in Value{Serializer,Deserializer}
>
> When FLAG_shared_string_table is true, postMessaging strings will share
> instead of copy.
>
> Note that not all operations on shared strings are supported, and shared
> strings may be slower than non-shared strings for some operations.
>
> Bug: v8:12007
> Change-Id: I3462128e15410d2568868143571571b3025722c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78614}
Bug: v8:12007
Change-Id: I5d9b99b2dac6f26d5ef046d7aec94f1a1d219419
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3389533
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78761}
When sandboxed external pointers are enabled, external pointers now only
require 32 bits of storage space in a HeapObject. This CL does not shrink
the size of EmbedderDataSlots, which will happen in a follow-up CL.
Bug: v8:10391
Change-Id: I3cf8b68c3b985cf806a45183717f50462a88c281
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359629
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78754}
This is a reland of 91f08378bc
When the class scope does not need a context, the deserialized
outer scope of the initializer scope would not be the class scope,
and we should not and do not need to use it to fix up the allocation
information of the context-allocated variables. The original patch
did not consider this case and resulted in a regression when we
tried to reparse the initializer function to look for destructuring
assignment errors. This fixes the regression by not deserializing
the class scope that's going to be reparsed, and using the positions
of the scopes to tell whether the scope info matches the reparsed
scope and can be used to fix up the allocation info.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: chromium:1278086, chromium:1278085, v8:10704
Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78745}
The allocatable registers have holes, so not all FP registers are one
half of a valid SIMD register. Thus check if {GetAliases} returned an
allocatable SIMD register before looking up if that register is being
used. Otherwise we run into a DCHECK because {simd_reg} is invalid.
The bug was only introduced recently: https://crrev.com/c/3404780R=thibaudm@chromium.org
Bug: chromium:1290079, v8:12330
Change-Id: I99df1645cfeec375daec82dbf41c110b5474339c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412075
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78742}
Moves between stack slots are rare; they mostly happen for tail calls
or for multi-return blocks. The bug exists since a long time, but was
only uncovered by the fuzzer now.
R=ahaas@chromium.org
Bug: chromium:1289678
Change-Id: Ibb0917717c6b7a468f5fcbb01be34267ba06a449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406749
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78736}
Changes:
- Rename kWasmTrapDataSegmentDropped to the more accurate ~OutOfBounds.
- Drop unused argument from {WasmCompiler::ArrayInit}.
- Rename {Factory::NewWasmArray} -> NewWasmArrayFromElements.
- Add error handling to {InitExprInterface}.
- Allow the data count section to appear anywhere in the module under
--experimental-wasm-gc. Add the same capability in
wasm-module-builder.js.
- Add {WasmArray::MaxLength(uint32_t element_size_log2)}.
- Add kTrapArrayTooLarge in wasm-module-builder.js.
- Small test improvements in gc-nominal.js.
Bug: v8:7748
Change-Id: I68ca0e8b08f906503f0d82e5866395018d216382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401593
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78730}
This is similar to the previous SIMD spilling fixes, but this time at
block merges. The logic is similar to the existing cases, but not quite
the same. I did not find a nice way to unify the different locations
where we check for SIMD register overlap.
R=thibaudm@chromium.org
Bug: chromium:1283395, v8:12330
Change-Id: I5ab9b6831368cbce40b8368e4ec7954e985bff96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404780
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78720}
The C-API does not support dynamic tiering and still waits for top-tier
compilation to finish before serializing code when the explicit
serialize() function gets called. This means that serialize() can only
finish if the kFinishedTopTierCompilation event was triggered first.
With this CL the kFinishedTopTierCompilation event is also triggered
after deserialization so that serialize() can work after
deserialization.
R=clemensb@chromium.org
Bug: v8:11024
Change-Id: I3dd14e37087e3cbfbc28cb5625c9f3715f6c236b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404773
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78719}
We used to serialize the full source code of the script being
serialized. This CL makes the source code maximally minimal (only
including the needed outer functions) while maintaining the "inner
function is textually inside its outer function" relationship.
Bug: v8:11525
Change-Id: Ic42772f7ecb76744bc11b97fa1784d847558e1f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401864
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78716}
Save the PC in the jump buffer and implement the suspend builtin.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I1a6d965d7864dce0a572f6c8d7102046dad190fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345006
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78715}
Allow Wasm to generate calls directly to Fast API C functions.
This massively reduces the overhead of these calls (~300%).
Currently options parameter is not supported.
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/3364356
with a fix to a data race.
Bug: chromium:1052746
Change-Id: I8c1c255419496d03a94ec2b443329842469586d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398394
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78714}
So far this flag was process-global, so if one isolate used v8::Locker
all isolates were forced to use v8::Locker. With the shared isolate
now being a thing that routinely gets migrated between different
threads, all users of the shared isolate would be forced to use
v8::Locker. So we now store that flag on the isolate such that using
v8::Locker for the shared isolate does not affect other isolates.
Deprecate v8::Locker::WasEverUsed() at the same time.
Bug: v8:11708
Change-Id: I60531f084cc1b1b113620c46f5bed20511f52c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401595
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78712}
This reverts commit 757830b02b.
Reason for revert: Speculatively revert due to a number of
performance regressions
Original change's description:
> [Torque] Generalize Torque literals to larger size
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Bug: v8:7793
> Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78671}
Bug: v8:7793
Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78706}
Split method into ShouldRecordRelocSlot and ProcessRelocInfo.
ProcessRelocInfo can then be reused in the write barrier and in the
future for the OLD_TO_SHARED remembered set. SlotTypeForRelocInfoMode
got moved into ProcessRelocInfo.
In addition rename and document SlotTypes. This CL does not change
behavior.
Bug: v8:11708
Change-Id: Iff712e7e6f5d3a4da64510b67b604b9e04998361
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400968
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78701}
Use the FatalProcessOutOfMemory function such that tooling recognizes
these crashes as OOM's.
Drive-by: Skip one more test that leads to such stack overflows.
Fixed: v8:12555, chromium:1288456
Bug: v8:12472
Change-Id: Ib9203a4aa0487744f7cea9a212aeeffda579ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401861
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78692}
This is a regression test for the fixes in
https://crrev.com/c/v8/v8/+/3299592 . Some of the helper functions were
copied from console-retaining-path.js in the same directory.
Bug: v8:12112
Change-Id: I3c313ad003ede5e5036f886161e1d164c98f87fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400149
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78689}
super.property accesses in heritage positions like `class C extends
super.property` should resolve super in the current scope, not C's
class scope.
Bug: chromium:1282096
Change-Id: I7ef815bc02cfff35a2898ef9f39b133d1114046c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400150
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78687}
Also:
- Refactor the ValueSerializer tests using raw data, so that we test all
valid versions for each test (not only one hard-coded one)
- Mark some tests as backwards compatibility tests, to make it less
likely that somebody updates them not realizing they are backwards
compatibility tests.
Bug: v8:11111, v8:12532
Change-Id: I670849de07742c8d442249ef4f013781e4ee9255
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386802
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78681}
This is a reland of f1c2a2089d
Changes compared to original:
Revert test change which used simd and caused problems in multiple test
configurations.
Original change's description:
> [wasm] Various small cleanups/fixes
>
> Changes:
> - Fix a bug in objects-printer where array elements were not treated as
> tagged pointers.
> - Fix a few TODOs, mainly in the wasm interpreter.
> - Improve documentation, small refactorings.
>
> Change-Id: I1d70ad454b3a0693b9b784b17395434d81d01b61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383136
> Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78656}
Change-Id: I91f4fed5fbc91acb8b42413a6f40a8202bd43096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398111
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78677}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. To help in this case, this CL introduces a new
CDP method "Runtime#getExceptionDetails" that behaves exactly as
advertised: It provides a populated "ExceptionDetails" structure
from a JS Error object.
R=bmeurer@chromium.org
Doc: https://bit.ly/runtime-get-exception-details
Bug: chromium:1278650
Change-Id: I084be10c1d852d3b7cac8d88e7f820e867be4722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337258
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78676}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Bug: v8:7793
Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78671}
Apply case-insensitive comparisons not only for the initial character,
but for the entire prefix. This avoids degenerate behavior for patterns
like /aaaa|AAAA|AAAA/i (i.e. generate a single 4-char prefix instead of
four 1-char prefixes).
Bug: v8:12472
Change-Id: Ib2b49fe73ca846a1b7ec90056cc64bdf5cf33026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398114
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78668}
Recursive ToNode node generation may overflow the stack for large
graphs. As a quick fix, insert periodic stack overflow checks in
selected ToNode methods.
As a more permanent fix, in the future we could abort gracefully
(instead of crashing on a CHECK), and/or refactor into iterative node
generation.
Bug: v8:12472
Change-Id: Ie5fbe838c5f6a5192d7d9b44bfe6f6c76a8d26e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398112
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78667}
These tests cover the basic VirtualAddressSpace functionality for the
three different types of address spaces currently available: the root
space, subspaces, and emulated subspaces.
This CL also includes minor bugfixes in VirtualAddressSpace
implementations and removes RandomizedVirtualAlloc in platform-win32.cc
which doesn't seem to do anything useful anymore but prevents page
allocation hints from working correctly.
Bug: v8:10391
Change-Id: Ifa260d18fd366516b5a41ab42ce2f1785c57d061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386801
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78666}
This reverts commit bd72152e7d.
Reason for revert: TSAN reports a data race, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18124/overview
Original change's description:
> [fastcall] Add Wasm entry for Fast API calls
>
> Allow Wasm to generate calls directly to Fast API C functions.
> This massively reduces the overhead of these calls (~300%).
> Currently options parameter is not supported.
>
> This is a rebase of the work originally done by devsnek in:
> https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
>
> Bug: chromium:1052746
> Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#78664}
Bug: chromium:1052746
Change-Id: I957708cf1cff6ee8f90678ee48428f5c12f75a53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398121
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78665}
Allow Wasm to generate calls directly to Fast API C functions.
This massively reduces the overhead of these calls (~300%).
Currently options parameter is not supported.
This is a rebase of the work originally done by devsnek in:
https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
Bug: chromium:1052746
Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78664}
Previously, StoreOwnIC incorrectly reuses the [[Set]] semantics
when initializing public literal class fields and object literals in
certain cases (e.g. when there's no feedback).
This was less of an issue for object literals, but with public class
fields it's possible to define property attributes while the
instance is still being initialized, or to encounter existing static
"name" or "length" properties that should be readonly. This patch
fixes it by
1) Emitting code that calls into the slow stub when
handling StoreOwnIC with existing read-only properties.
2) Adding extra steps in StoreIC::Store to handle such stores
properly with [[DefineOwnProperty]] semantics.
Bug: v8:12421, v8:9888
Change-Id: I6547320a1caba58c66ee1043cd3183a2de7cefef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300092
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78659}
Changes:
- Fix a bug in objects-printer where array elements were not treated as
tagged pointers.
- Fix a few TODOs, mainly in the wasm interpreter.
- Improve documentation, small refactorings.
Change-Id: I1d70ad454b3a0693b9b784b17395434d81d01b61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383136
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78656}
This CL introduces a dedicated API to retrieve the current (w.r.t. the
JS stack) script name or sourceURL. Currently, API clients will
collect multiple stack traces in increasing sizes to accomplish the
same goal. The new method walks the JS stack in the same way as the
stack trace collection mechanic but doesn't create/allocate stack info
or callsite objects along the way.
R=bmeurer@chromium.org, yangguo@chromium.org
Doc: https://bit.ly/v8-current-script-name
Bug: chromium:1286677
Change-Id: Id53e4f04bf17349d34f3d581bc712b1f4aa055db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3382818
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78645}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
The receiver is included unconditionally on all platforms
(kJSArgcIncludesReceiver is always true).
Remove all usages of kJSArgcIncludesReceiver from the code.
Bug: v8:11112
Change-Id: I7d62e6de65b73fe6d8c3293f32b500b760b08a3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322980
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78642}
The fast path has an early return if the two inputs are the same
object. However, this was missing the check that the receiver
is not undefined required by the spec.
This fixes it by first checking that the receiver is a string and
only afterwards checking for reference equality.
Bug: v8:12495
Change-Id: I4c5fc80e09060b013c94b05bbc9da504ddbb5206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386602
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78637}
Shell::FetchModuleTree assumes that the module at file_name wasn't
already fetched. Shell::ExecuteModule is calling into
FetchModuleTree without checking if the module is already in the module
map, violating this assumption.
This change fixes this by having Shell::ExecuteModule check for the
existence of the module before calling into Shell::ExecuteModule, the
same way that Shell::DoHostImportModuleDynamically does.
Bug: v8:12530
Change-Id: Ia038cbd1715e85c9c92c4554fd486c657ef952e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388130
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78636}
Similar to the case of fixed registers, we need to consider both cases:
A SIMD register might collide with either the low or high FP register,
or the FP register might collide with a previously allocated SIMD
register. We did only consider the first case so far.
R=thibaudm@chromium.org
Bug: chromium:1286253, v8:12330
Change-Id: Id4c995586cc8b97a2e131ee9d3417525e409bcef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380597
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78633}
This is a reland of 142dd775b4
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
- Add suspend asm builtin stub, and call it from the suspending
wasm-to-js wrapper
- Rename frame type to match both builtins (prompt and suspend)
- Add suspend bool to the import cache key
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ie5a8ca7cbe4bcb91697e05b6470e3d632d608993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345004
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78628}
Since ManualGCScope changes marking flags it should finalize any
ongoing GC before changing the flags. Otherwise, the GC may observe
inconsistent state.
Bug: chromium:1285706
Change-Id: Ie8ef6a1117ba0523d0bed0c46d9116ffbc02069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386607
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78618}
When FLAG_shared_string_table is true, postMessaging strings will share
instead of copy.
Note that not all operations on shared strings are supported, and shared
strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I3462128e15410d2568868143571571b3025722c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78614}
This reverts commit 142dd775b4.
Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78605}
https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.
This CL adds the standard marker snapshot protocol for embedder fields.
Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot
Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields
This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
can use it as dependency for the concurrent fast path.
Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
This CL fixes 2 issues with string internalization when the string table
is shared:
1. In-place migration of a string's map to Internalized was done before
it was sure that the string is going to be internalized (outside the
critical section). To fix this problem StringTableKey::AsHandle() is
now split into StringTableKey::PrepareForInsertion(), which is
invoked outside the critical section and creates a copy if
necessary, and StringTableKey::GetHandleForInsertion(), which is
invoked inside the critical section only for string table misses.
Migration of the map is handled by this method.
2. TryStringToIndexOrLookupExisting() didn't handle already internalized
strings. So far this was impossible, as this method was only invoked
for strings that were checked not to be internalized. However with
a shared string table, the string could be internalized after the
checks.
Bug: v8:12007
Change-Id: I193d6b54dc41360eee47d21cbcaa36d2652d85dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368103
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78600}
This unifies and simplifies the way we instrument async functions for
the purpose of async stack traces and async stepping. It does so while
retaining the observable behavior on the inspector level (for now).
Previously we'd mark the implicit promise of the async function object
with the async task ID, and whenever we awaited, we'd copy the async
task ID to the throwaway promise that is created by the `await`. This
however made things unnecessarily interesting in the following regards:
1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
`AsyncFunctionFinished` events, coming from the throwaway promises,
while the implicit promise is "done". This is especially confusing
with rejection propagation and requires very complex stepping logic
for async functions (after this CL it'll be possible to unify and
simplify the stepping logic).
2. We have to thread through the "can suspend" information from the
Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
to the async function instrumentation to decide whether to cancel the
pending task when the async function finishes.
This CL changes the instrumentation to only happen (non recurringly) for
the throwaway promises allocated upon `await`. This solves both problems
mentioned above, and works because upon the first `await` the stack
captured for the throwaway promise will include the synchronous part as
expected, while upon later `await`s the synchronous part will be empty
and the asynchronous part will be the stack captured for the previous
throwaway promise (and the V8Debugger automatically short circuits
stacks with empty synchronous part).
Bug: chromium:1280519, chromium:1277451, chromium:1246867
Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78599}
CompleteInobjectSlackTracking potentially shrinks multiple maps, and
the relation between these maps should be preserved in a concurrent
environment. Thus it is not enough to make each modification
atomically, but all related map modifications must be within a
critical section.
We do this by locking the map_updater_access mutex
CompleteInobjectSlackTracking, and hence moving the function to the
MapUpdater class.
Bug: chromium:1274445,v8:7990
Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78597}
The last update (using tools/wasm/update-wasm-fuzzers.sh) was in
November 2020, thus update again to add modules from all existing tests
to the corpus used by ClusterFuzz.
This increases the number of files in the corpus from 47196 to 53779.
R=ahaas@chromium.org
Change-Id: Ie293bda0b4d5d7c34d5b7c53d8115d9d3883f1db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379813
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78590}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. This means we can't reuse Isolate::CreateMessage as
the JS stack at call time is unrelated to the time when an Error
object was thrown.
To re-use some of the code, this CL introduces a new
"CreateMessageFromException" method that is only available from the
debugging interface (not public V8 API!). The new method works
similar to Isolate::CreateMessage, but:
1) Does not look at the current JS stack, neither for a fresh
stack trace nor for location information.
2) Only uses the "detailed" stack trace for location info.
This is because the "simple" stack trace could have already
been serialized by accessing Error#stack.
Bug: chromium:1278650
Doc: https://bit.ly/runtime-get-exception-details
Change-Id: I0144516001c71786b9f76ae4dec4442fa1468c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337257
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78586}
This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
This CL doesn't change behavior, only refactors MemoryAllocator:
* De-templatify class, MemoryAllocator is used on slow path and doesn't
really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class
Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
We introduce {ConstantExpression}, which represents the most frequent
constant expression types directly, and falls back to a {WireBytesRef}
for the rest. During module decoding, we decode the most common
expressions separately and store them as {ConstantExpression}, so we do
not have to decode them again during module instantiation.
Bug: chromium:1284557
Change-Id: Ie411bbe9811d0d9f6e750ba202bb0ccff801dfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378347
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78576}
It is possible for KeyedDefineOwnICKind to go into
ElementsTransitionAndStoreIC_Miss when a computed field key
is a valid index and the lazy feedback allocation is disabled.
Bug: chromium:1277863
Change-Id: If8a81384257647426607495b6e3d8f235913e8f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322634
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78573}
This is a temporary solution so prototyping of shared structs and shared
strings can be worked on in parallel.
Bug: v8:12007
Change-Id: Ic849ec66da1d3824d50d695f16e4b77380afa015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379222
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78570}
V8 crashed with a FATAL when memory allocation during instantiation
failed. With this CL, a RangeError is thrown instead.
This is not the only possible OOM that can happen during the startup of
a WebAssembly app, but since the allocation of WebAssembly memory is
among the biggest allocations, this change may already prevent several
crashes.
R=clemensb@chromium.org
Bug: chromium:1268898
Change-Id: I9376830ba2fe9df62b5595b6b19c92e35a75dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380586
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78569}
We introduce a type arrayref, which is a supertype of all array types
and a subtype of dataref. We change array.len to accept values of type
(ref null array).
Drive-by: Fix kEq/kData case in TypecheckJSObject.
Bug: v8:7748
Change-Id: I47c6a4487ddf5e7280c1427f43abe87a97c896bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78565}
The original CL introduced a test that does not work when it is executed
concurrently on multiple isolates. This CL skips this test
configuration.
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
Change-Id: I36ce90b37736172aa01c47ab04e154ec8ea2d8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380590
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78564}
- Add Suspender.suspendOnReturnedPromise method
- Extend the WasmApiFunctionRef data with the suspender
- Detect wrapped WasmJSFunctions when we resolve the import
For now the generated wrapper is still a regular wasm-to-js wrapper, but
this sets the ground for generating specific wrappers for functions
wrapped by suspendOnReturnedPromise, and to access the suspender from
the wrapper code.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I81cbec6b023507e47e6e1463b5f9b912f807da6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345000
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78560}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
We should only check the "SIMD sibling" register if we are handling a
SIMD register. This avoids unneeded spills, and in this particular case
ran into a DCHECK because there are only 29 registers, but we tried
checking #29.
R=thibaudm@chromium.org
Bug: v8:12330, v8:1285007
Change-Id: Ife8b295ac958990611ca8816bbfbfb5124a4297d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372916
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78532}
This should have been updated in https://crrev.com/c/3370408
Bug: chromium:1284506
Change-Id: Ie44d80b507c9a798ce6f4776672270f9d4b12195
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3371463
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78519}
The test was added in https://crrev.com/c/3372910, but needs to be
skipped on non-SIMD hardware because it contains SIMD instructions.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Ifaede466b24aea4f9ef6b062414a31698bcca864
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372917
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78517}
Spilling was already fixed if a fixed SIMD register overlaps with an
allocated FP register, but the other way around was missing: If an odd
FP register (in this case d1) is used as a fixed output register, but
this register is in use as the upper half of a SIMD register (in this
case q0), we did not detect this and would just use overwrite the SIMD
half.
This CL also fixes this case.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Id3f98b7accd77e38ab4cd5ff8910aaf5ad96a1ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372910
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78514}
https://crrev.com/c/3297708 changed the serialization format for typed
arrays without bumping the format version. As a consequence, builds that
include that CL fail to deserialize typed arrays serialized by previous
V8 versions.
This CL reverts the serialization format change, and does minimal test
changes to reflect the revert. https://crbug.com/v8/12532 tracks
serializing typed array flags in a backwards-compatible manner.
Bug: chromium:1284506
Change-Id: Ib32e88c6383e0ad4ad1a9ff63f413a1eb123b1ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3370408
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78507}
We implement loop peeling for wasm, currently available behind a flag.
Loops are peeled regardless of size.
Bug: v8:11510
Change-Id: Ia4c883abdee83df632b2611584d608c44e3295c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367615
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78496}
