Runtime.executionContextCreated provides many details in
ExecutionContextDescription structure while
Runtime.executionContextDestroyed provides only executionContextId. This
information is insufficient for the clients that use uniqueContextId.
Bug: v8:12896
Change-Id: I31df0ed618dc1c8b55c7eba8f96eeaef2d4de6c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3657439
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Vladimir Nechaev <nechaev@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85110}
The debugger utilizes the source position while single stepping
("Step-in") through the source to go from statement to statement and
skipping some expressions along the way. The debugger remembers the
"statement position" of the last stepping action.
This works well in general but falls flat for loops that only have
a single statement in them. Every step lands on the same statement,
just one loop iteration later.
We detect this case by checking if we are in the same frame and have
the exact same bytecode offset as the last step action.
Note that this also fixes "frame restarting" should we have restarted
a function while paused at the beginning of that function.
R=jarin@chromium.org
Bug: chromium:1401674
Change-Id: Id0a5753ed7cc9f23f22d869368d88e1c4b48566d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135881
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85107}
This CL fixes a bug where we wouldn't pause (or even crash) when trying
to interrupt an infinite loop.
When we pause via stack check (i.e. a scheduled break) we currently do
one additional step-in. We do so to enter functions properly in case
we are paused in the middle of setting up the stack frame.
Loops also do a stack check, to support pausing infinite loops. In
that case we can skip the additional step-in as we are already
in a valid pause position (as implemented by this CL).
This CL also removes two bogus DCHECKs. We assumed that
a scheduled break never happens after a step. This is wrong, e.g.
a user can click the pause button after stepping over a long running
function.
Note that we duplicate the various loop interruption cctests to
also interrupt the loops with the "scheduled" break reason. Without
the changes in debug.cc, those won't pass.
The CL https://crrev.com/c/4136058 adds a regression test on the
blink side.
R=jarin@chromium.org
Fixed: chromium:1401674
Change-Id: I42b44744b17d24351f01b83c0446908c24e6c5fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134246
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85106}
Delay the "max steps" check until the frame is fully set up. This means
that the work is already done at the point where we check the maximum
number of steps, but the additional work is limited by the maximum
number of locals and parameters.
R=thibaudm@chromium.org
Bug: chromium:1404619
Change-Id: I4919c837feea92af84f99182a571edf96e4728ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135890
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85098}
The expected behavior of the optimized code is deoptimizing when using a BigInt
as an index and throwing an error (from CheckedTaggedToInt64).
The representation changer tries to insert conversions for this case where
- The output node is represented in Word64 (SignedBigInt64)
- The use info is CheckedSigned64AsWord64
The representation changer first rematerializes the output node to
TaggedPointer because the type check is not BigInt. Then it falls wrongly to
the branch where the output representation is TaggedPointer, the output type is
SignedBigInt64 in GetWord64RepresentationFor.
Bug: v8:9407, chromium:1403574, chromium:1404607
Change-Id: I9d7ef4c94c1dc0aa3b4f49871ec35ef0877efc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135876
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#85094}
Increase length of strings in the test to ensure they are cachable
external strings even when the sandbox is disabled.
Change-Id: I1228e1abb1d88c0bb70edaeb718e1bf2f4cdd53d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127228
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85081}
With lazy compilation we disabled mprotect-based code protection. We
currently have no users and no test coverage of that flag. Hence remove
it from the code base.
R=ahaas@chromium.org
Bug: v8:13632
Change-Id: I1e39499dfbdb896287901b97c32f00366449c466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4114296
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85080}
EmbedderStackStateScope is used to disable conservative stack scanning
for cppgc when the stack is known to not contain heap pointers. Also,
DisableConservativeStackScanningScopeForTesting is used to disable CSS
for the V8 heap in tests that assume a precise GC. Until now, these two
have used two different mechanisms for disabling CSS. This CL merges
the two mechanisms and implements the latter scope via the former.
This is a reland of commit f51e0bb1db
reviewed on https://chromium-review.googlesource.com/c/v8/v8/+/4111954
Bug: v8:13257
Change-Id: Ia124a4201686e0ea79f9cd07bc3888b9781cafa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128141
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85066}
This removes EmbedderHeapTracer from V8's API. Going forward
v8::TracedReference is only supported with using CppHeap (Oilpan).
Bug: v8:13207
Change-Id: I4e0efa94890ed147293b5df69fd7e0edad45abb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111546
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85061}
When internalizing external strings, a new internalized external string object is allocated if the string is not in-place internalizable. This newly allocated strings external resource is set to null (the actual resource will be transferred by MakeThin to ensure unique ownership of the resource).
We need to preserve the original string in the InternalizedStringKey for
the second lookup (inside the critical section), as we need to access
the external resource in case of hash collisions to check for equality.
Bug: chromium:1402187
Change-Id: I62b637859b06f05d1b34cb26495f08ec44d2f2db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128089
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85057}
This reverts commit 84e470845a.
Reason for revert: Breaks TSAN stress-incremental-marking: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10433/overview
Original change's description:
> [wasm][capi] Optimize all functions before serialization
>
> The existing implementation of `serialize` in the C-API is to produce
> a snapshot of the current state of the `NativeModule`. However, so far
> all users of `serialize` did not care about the runtime of `serialize`,
> but cared about `deserialize` starting up fast.
>
> With this CL all functions of a module get tiered up to TurboFan before
> serializing the module.
>
> R=clemensb@chromium.org
>
> Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85052}
Change-Id: Ie0758b32ef3469fe75d3a45bc3e6950b3b192edb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4131634
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85053}
The existing implementation of `serialize` in the C-API is to produce
a snapshot of the current state of the `NativeModule`. However, so far
all users of `serialize` did not care about the runtime of `serialize`,
but cared about `deserialize` starting up fast.
With this CL all functions of a module get tiered up to TurboFan before
serializing the module.
R=clemensb@chromium.org
Change-Id: Icaef846e33509d90b38559c0b689f798d35a98db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4129495
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85052}
TurboAssembler::Switch considers its "condition" input is 64-bit.
However, Maglev's inner integers are rather Smis/32-bit integers.
Because we didn't not sign-extend the condition before calling
TurboAssembler::Switch, negative values were treated as positive
rather than negative.
Fixed: chromium:1403749
Bug: v8:7700
Change-Id: I78e934045330012186dc83dea0dc620ec977380a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128080
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85049}
`CpuProfiler::StopProfiling()` return `nullptr` if no profiling is
active. Thus a `nullptr` check is needed before serializing the profile
returned by `CpuProfiler::StopProfiling()`.
R=clemensb@chromium.org
Bug: chromium:1394663
Change-Id: I364eeb1d9bd670de5179e242c4462f0fbfc9c607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4126234
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85047}
.. which should result in 0 if x is non-negative, and -0.0 otherwise.
- Fix two invalid modulus-related folds.
- Handle aliased inputs in Int32ModulusWithOverflow.
- Drive-by: rename left/right to lhs/rhs to match the algorithm
description.
Note there is no deopt loop here since a result of -0.0 will update
feedback to kSignedSmallInputs.
Bug: v8:7700
Change-Id: I84fca0e43ded152d3520cbe73cc43299ff1c4230
Fixed: chromium:1403575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128081
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85039}
The Sub macro sometimes needs a scratch register when the 2nd operand
is too large to be encoded in the instruction. The prologue was
already reserving 2 scratch registers, which made Sub crash on a
DCHECK when trying to reserve one more scratch register.
Bug: v8:7700
Change-Id: I995689b8b16e3ef216641f0b6cadbf58f7f3740b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128554
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85029}
Mark rhs as clobbered since we may negate it. Negate the lhs in rax.
Bug: v8:7700, chromium:1403470
Change-Id: I9a26de78fcd8d1db90c1d26617001c0c699c350e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110814
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85021}
As a drive-by this also fixes property load from smi. We still need to check that we actually have a smi...
Bug: v8:7700, chromium:1403280, chromium:1403323
Change-Id: I3c4f050b94550b8d7e4e65f733f9c1dad47941d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120575
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85015}
Even if we have a constant load, if the map is not stable, we cannot
guarantee that the load is preserved across side-effecting calls.
Fixed: chromium:1403324
Bug: v8:7700
Change-Id: Ib900cf7574711115439e6521ed8cfaa866525e78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123532
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85014}
It's possible that various branches merged already with a value that's
in a liveness hole, but we only figure out later. If so, drop the merge
as well.
Bug: v8:7700, chromium:1403399
Change-Id: Ifd97e0c1959ffe51017e400fb028041047885a9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111932
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85013}
The issue causing this test to fail on the usban bot was fixed with
https://crrev.com/fcda478d890caea6bf04a50e6106682b64cf8d5a
Bug: v8:13611, v8:13612
Change-Id: I1d0a713160cdddf8623e767d43277a988509bce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110955
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85007}
This CL plugs the hole in the outside<-ShadowRealm direction (i.e.
getting a reference to an object inside of the ShadowRealm from outside
the ShadowRealm).
This is a follow-on CL to
https://chromium-review.googlesource.com/c/v8/v8/+/4108810, which
plugged the getFunction hole in the ShadowRealm<-outside direction (i.e.
getting a reference to an object outside of the ShadowRealm from inside
the ShadowRealm).
Bug: v8:1198
Change-Id: Ic06533ba8b1cc6477ef9d55a23cb8b0b6584d4a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4115657
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85003}
With smi feedback, we use int32 operations for arithmetics.
When negating 0, we have to fallback to float as we can't represent -0
in int32. We can simply deopt in that case without causing a deopt loop, as a non-smi result will change the feedback to kSignedSmallInputs (from kSignedSmall).
Bug: chromium:1403102
Change-Id: Ic27c267349a1de6904639e91b1cade2c4f7d1fe2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122829
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84998}
This CL introduced four more operators in TurboFan: BigIntLessThan,
BigIntLessThanOrEqual, and the corresponding speculative operators so
that all the BigInt comparisons are supported.
This CL also implemented fast paths for small BigInt inputs.
Bug: v8:9407
Change-Id: Iaa2d4dbebf68656d775a7feb65b97fb5c598ec23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111951
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84995}
After https://crrev.com/c/3859787 those frames would be printed like
standard Wasm frames, but in the place of the WasmInstanceObject, they
have a WasmApiFunctionRef object instead.
So special-case the {WasmToJsFrame::instance()} to load the instance
properly. Also special-case the {position()} accessor for imported
functions.
R=victorgomes@chromium.org
Bug: chromium:1402270
Change-Id: I39805805a50e7a73d7d8075c63c46bdf5a373a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116778
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84993}
It's failing regularly on the ubsan bot, closing the tree.
This CL also adds a 'variant == future' section in the mjsunit.status
file to enable easy disabling of maglev-specific failures.
No-Tree-Checks: true
Bug: v8:13612
Change-Id: I3c0f7725e1fb36577e97c662cd3830c64ba298e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120554
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84982}
This reverts commit 2a71e8637f.
Reason for revert: This probably blocked the V8 roll.
https://chromium-review.googlesource.com/c/chromium/src/+/4116621?tab=checks
Original change's description:
> Reland "[heap] Fix conservative stack scanning for client isolates"
>
> This is a reland of commit 36bac1bcae
>
> Original change's description:
> > [heap] Fix conservative stack scanning for client isolates
> >
> > With this CL, the context of stacks corresponding to all client isolates
> > are saved, so that conservative stack scanning can be used correctly
> > during a shared garbage collection. This happens:
> >
> > 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> > isolate and the initiator;
> > 2) when an isolate's main thread is waiting in a safepoint; and
> > 3) when an isolate's main thread is parked.
> >
> > Bug: v8:13257
> > Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Reviewed-by: Omer Katz <omerkatz@chromium.org>
> > Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#84712}
>
> Bug: v8:13257
> Change-Id: I61df6eeca5a28e04eb3a858f7d601bc5f6312e49
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092737
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84963}
Bug: v8:13257
Change-Id: I3a235f11e5fe55c476591a5274946aeb6cc9bf6e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111178
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84973}
This reverts commit f51e0bb1db.
Reason for revert: Dependent on crrev.com/c/4092737 that is being reverted.
Original change's description:
> [heap] Merge mechanisms for disabling CSS
>
> EmbedderStackStateScope is used to disable conservative stack scanning
> for cppgc when the stack is known to not contain heap pointers. Also,
> DisableConservativeStackScanningScopeForTesting is used to disable CSS
> for the V8 heap in tests that assume a precise GC. Until now, these two
> have used two different mechanisms for disabling CSS. This CL merges
> the two mechanisms and implements the latter scope via the former.
>
> Bug: v8:13257
> Change-Id: Ieca082657854fe2eff9eb5d95a30d48bb8eab44f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111954
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84964}
Bug: v8:13257
Change-Id: Id769af6215a2ed319ec96b354734a5362b2384cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111179
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84972}
EmbedderStackStateScope is used to disable conservative stack scanning
for cppgc when the stack is known to not contain heap pointers. Also,
DisableConservativeStackScanningScopeForTesting is used to disable CSS
for the V8 heap in tests that assume a precise GC. Until now, these two
have used two different mechanisms for disabling CSS. This CL merges
the two mechanisms and implements the latter scope via the former.
Bug: v8:13257
Change-Id: Ieca082657854fe2eff9eb5d95a30d48bb8eab44f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111954
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84964}
This is a reland of commit 36bac1bcae
Original change's description:
> [heap] Fix conservative stack scanning for client isolates
>
> With this CL, the context of stacks corresponding to all client isolates
> are saved, so that conservative stack scanning can be used correctly
> during a shared garbage collection. This happens:
>
> 1) in Heap::PerformSharedGarbageCollection, for the stacks of the shared
> isolate and the initiator;
> 2) when an isolate's main thread is waiting in a safepoint; and
> 3) when an isolate's main thread is parked.
>
> Bug: v8:13257
> Change-Id: I9ff060f2c0c1ec12977c70d67d65d9c543e2d165
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027210
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84712}
Bug: v8:13257
Change-Id: I61df6eeca5a28e04eb3a858f7d601bc5f6312e49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4092737
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84963}
The spec does not allow side effects on wrapping the exceptions
crossing the realm boundaries. We need to provide an easy way to inspect the exception-thrown cross-realms according to the last TC39 meeting
consensus.
Related spec change: https://github.com/tc39/proposal-shadowrealm/pull/382.
Bug: v8:11989
Change-Id: Ia78d94fd33cba689267aeacd028d662bd4a37fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3618759
Commit-Queue: Chengzhong Wu (legendecas) <legendecas@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84961}
With this change property accesses on WasmObject and WasmArray return
undefined instead of throwing.
Furthermore retrieving the prototype of a WasmObject/WasmArray returns
null.
Bug: v8:13523
Change-Id: I12e3b9fb6ac9a7305f001a3b3835854068c3064f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110995
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84957}
We add final types to wasm-gc.
- We introduce a `kWasmSubtypeFinalCode` as an alternative to
`kWasmSubtypeCode`.
- Behind a flag, we interpret types behind this code as final, as well
as types outside a subtype definition by default.
- For final types, type checks for call_indirect and ref.test etc. are
reduced to simple type identity checks.
Bug: v8:7748
Change-Id: Iabf147b2a15f43abc4c7d1c582f460dbdc645d66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4096478
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84955}
Error mode: a TypedArray backed by RAB claims it's not backed by RAB.
Drive-by: disable resizability even harder when --harmony-rab-gsab is
not on.
Bug: v8:11111, chromium:1402139
Change-Id: I937c69f6124419cc8d29da0195686bc3b9a5c281
Fixed: chromium:1402139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110751
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84952}
- Converts tests in EmbedderTracingTest to UnifiedHeapTest
- Move EmbedderRootsHandler tests to their own file
- Adds support for CppHeap in ManualGCScope
- Drive-by fix typo
Reland: Fix issue with attaching a CppHeap while incremental marking
is already running.
This reverts commit d90a98edc1.
Change-Id: Ifafa9145df3103578c4c7f1b3b0336b4bd9f34dd
Bug: v8:13207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110941
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84950}
ShadowRealms have a callable boundary: there cannot be any edges between
objects in the ShadowRealm and those from other realms. V8's
prepareCallStack API breaks this invariant via getFunction() and
getThis(). This CL makes those functions throw when called inside
ShadowRealms.
See also
https://docs.google.com/document/d/1aXEy4YCC9CduxLs7MGw-UOm0P4OuG7W-cScBnLG3ALI/edit?usp=sharing
Bug: v8:11989
Change-Id: I5a2b8fa735c0f10583c8cede4062645986b2d914
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4108810
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84944}
