We currently add two samples: One for the overall wire bytes size and
one for the number of declared functions. Both is not only available
during decoding, but also to the caller. Hence separate the update of
counters and events from actual decoding. This will make it simpler to
decode a module (for re-validation) without updating counters.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Ib00f4150cf2ad5452090f0aff8198b31d075b49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061687
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84538}
This reverts commit e31a7192ee.
Reason for revert: TSAN failure for the newly added unittest: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10056/overview
Original change's description:
> Reland "unified-young-gen: Implement generational barrier for TracedHandles"
>
> The dcheck was fixed in 7b40cb0c1b. The MSVC was also fixed.
>
> Original change's description:
> > unified-young-gen: Implement generational barrier for TracedHandles
> >
> > If unified young generation is enabled, we don't record all young nodes,
> > but only ones that have old host. The same std::vector<TracedHandle*> is
> > reused for the remembered set implementation.
> >
> > The barrier is added to TracedHandle creation, i.e.
> > - v8::TracedReference::Reset(),
> > - v8::TracedReference::operator=(const TracedReference&),
> > and to moving between TracedHandles, i.e.
> > - v8::TracedReference::operator=(TracedReference&&).
> >
> > Bug: v8:13475
> > Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#84513}
>
> Bug: v8:13475
> Change-Id: I8ecde011af077a818b7b96af57e15b607febb185
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061693
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84533}
Bug: v8:13475
Change-Id: I05a179a5ef79890640bba450c4f3e3178c38228f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061464
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84536}
The dcheck was fixed in 7b40cb0c1b. The MSVC was also fixed.
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I8ecde011af077a818b7b96af57e15b607febb185
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061693
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84533}
Fuzz parallel moves that may modify the stack layout in
cctest/test-code-generator. This requires some changes in the test
environment to keep track of the the input and output layouts.
R=dmercadier@chromium.org
Bug: chromium:1269989
Change-Id: I872bf5d79b8275595f21fa9236e4634331078053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4047488
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84530}
When TurboFan generates code for TypedArray access for which we have
seen different ElementsKinds, we might end up accessing the TypedArray's
length directly when we are inlining into a call site where the
TypedArray is known. This access could also happen for ElementsKind
cases that are different from the actual TypedArray, which caused a
DCHECK failure for cases where length access is prohibited (e.g. for
rab/gsab backed TAs).
Since these cases are not reachable at runtime, this CL removes the
incorrect length access and generates an Unreachable node in the graph
instead.
Bug: chromium:1393942
Change-Id: I1171531210bf6d1f14a58c4beefb0a3b70a646cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061314
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84524}
1) Parameter conversions resizing the underlying buffer but *not* in a way that would make a length-tracking TA go OOB.
2) Special case of the former: resize to 0.
Bug: v8:11111, chromium:1392577, chromium:1393375
Change-Id: Ia0f54fc4530618fa2313737d6c643abdb24b9a36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055630
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84519}
This reverts commit d164f933b8.
Reason for revert: Failure on YoungUnifiedHeapTest: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20no%20pointer%20compression%20debug/1954/overview (Mac arm64)
Failure on Linux: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/51267/overview
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I0d97f8cdd0b2e95c7a21b78dacd25c38d08f5a16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062087
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84516}
If unified young generation is enabled, we don't record all young nodes,
but only ones that have old host. The same std::vector<TracedHandle*> is
reused for the remembered set implementation.
The barrier is added to TracedHandle creation, i.e.
- v8::TracedReference::Reset(),
- v8::TracedReference::operator=(const TracedReference&),
and to moving between TracedHandles, i.e.
- v8::TracedReference::operator=(TracedReference&&).
Bug: v8:13475
Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84513}
Currently V8 recompiles all functions of a WebAssembly module with
TurboFan when a debugging session ends. This is outdated behavior and
causes OOMs for developers. With this CL all debugging code gets removed
when a debugging session ends, and functions get re-compiled lazily.
This behavior may lead to slightly worse performance for some time after
debugging finishes, but it avoids OOMs, and developers are used to
debugging code being not as performant as production code.
R=clemensb@chromium.org
Bug: chromium:1372621, v8:13224
Change-Id: I9fc97408ef92ad5564f2a9743213762226c2b25e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055923
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84509}
PPC has a smaller wasm code space compared to other platforms and
as a result can't execute modules with large number of functions.
More details are available under the comment section of
crrev.com/c/4027963
Change-Id: I0531ec855ee9ffa5542bf0527287a3e49e1cdb0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4053377
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84491}
This test had to be updated for --shared-space because the main isolate
is always parked when the client isolate requests a GC. In such cases
the GC isn't performed and therefore the weak handle not reset.
The CL moves the client isolate into a proper thread which allows the
main isolate to remain in the running state.
In addition this CL adds the BasicMemoryChunk::ComputeMarkBit
methods. These methods make it easy during debugging to compute
the MarkBit (cell + mask) for an object.
Bug: v8:13267
Change-Id: I6680d8d1d8b36d86b22c43399abbd4325f64ccb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4054622
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84488}
If a value is used after a try-block finishes, we need to make sure that
the catch-block can restore its value. Otherwise we'd accidentally drop
the value on register merge thinking we're in a liveness hole on the
merge after the catch (since the catch cleared all the registers). This
then breaks JumpLoops that need to restore the value in a specific
register.
Bug: v8:7700, chromium:1392061
Change-Id: I7255ccf9b36bf36583ad612882137b251c48caed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055111
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84483}
HeapTest.GrowAndShrinkNewSpace emulates a GC cycle for shrinking new
space. Starting a new MinorMC cycle should first finalize sweeping from
the previous GC cycle.
Bug: v8:12612
Change-Id: Iea35b54ba0f7be3b7870c557c92042a8d9896045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055625
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84475}
The WasmModuleBuilder is used in tests for creating Wasm modules. It can
be pretty slow for huge modules, in particular in simulator builds or in
slow variants like gc-stress.
This CL adds a fast path to the code section creation, for functions
without locals. This makes the wasm-max-functions test 1.45x faster in
the arm64 simulator (generation of the code section alone gets 2.2x
faster).
R=ahaas@chromium.org
Change-Id: I993542448fb4f0b5fdadca13c59691d86844e2a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051606
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84465}
This reverts commit a63f9912b7.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/50370/overview
Original change's description:
> [maglev] Spill nodes that we'd otherwise fail to merge
>
> This makes sure that catch-blocks don't accidentally drop values that
> are only in registers, which can happen if we throw in deferred throwing
> code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
> such values when trying to merge after the catch block, noticing we
> can't find the value through the catch-block. Unfortunately it's not
> trivial to figure out where that merge happens, so we just
> unconditionally spill the value.
>
> For liveness holes (as the comment previously mentioned) the value
> should already be dead and dropped on the merge. Running --maglev-stress
> etc shows that no code currently hits this path, except for the added
> test that shows the issue with catch blocks.
>
> Bug: chromium:1392061
> Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84448}
Bug: chromium:1392061
Change-Id: Iddbd7b19bc73e352dbd6867db990238f80adbdda
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055504
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84455}
Function#call needs a function to call, so don't try to lower it to a
builtin call when there's no function.
Bug: v8:7700
Change-Id: I6705e2900731b2be2830231f8ab0dbfcdca5f594
Fixed: chromium:1392936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055680
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84451}
This makes sure that catch-blocks don't accidentally drop values that
are only in registers, which can happen if we throw in deferred throwing
code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
such values when trying to merge after the catch block, noticing we
can't find the value through the catch-block. Unfortunately it's not
trivial to figure out where that merge happens, so we just
unconditionally spill the value.
For liveness holes (as the comment previously mentioned) the value
should already be dead and dropped on the merge. Running --maglev-stress
etc shows that no code currently hits this path, except for the added
test that shows the issue with catch blocks.
Bug: chromium:1392061
Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84448}
A shared GC needs to reset weak global handles that store pointers
to shared objects which die during the shared GC.
Bug: v8:13267
Change-Id: I3800bf1173f42dd9ab96be4add462547b2a8f4a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051602
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84444}
The test is slow and timeouts easily.
R=manoskouk@chromium.org
Bug: chromium:1380561
Change-Id: I413891a73daa1f2ef9d9537b35b8543495a0ccac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4048122
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84430}
This is a reland of commit 7bf94d0336
Changes since revert:
- Update string forwarding table with evacuated objects in mark compact.
- Always mark forward objects in string forwarding table.
Original change's description:
> [heap] Transition/Shortcut strings only during GCs without stack
>
> By limiting transitions of (shared) strings and shortcutting of
> Thin/Cons strings to GC withouts stacks, optimizing compilers can rely on
> the invariant that string maps do not change during a GC, allowing them
> to eliminate map checks and enable more aggressive optimizations.
>
> Change-Id: Ic9c9ed7b04b2ceed369484bf048965c083a9a693
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030578
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84347}
Change-Id: I1ab0965ff421635457a66fbe7f178d951afe4402
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4035240
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84424}
This fixes a bug where the {types} vector automatically reserved
additional space, and by comparing with its capacity we failed to
register an out-of-bounds error.
Using capacity over size has led to bugs before, and using it correctly
(reserving as much space as needed manually) prevents vectors from
reserving space exponentially. Therefore we are switching to using size
for bounds checks instead.
Bug: v8:7748, chromium:1388942
Change-Id: I3cb8de4f113aaa6d70e45557161fd4c268861f1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4046221
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84419}
There exists a limit in the WebAssembly specification on the maximum
number of functions allowed in a module. For release builds the limit
seems high enough for now, but we got developer feedback that their
debug builds exceed this limit. To support these developers without
violating the specification this CL introduces a V8 flag that allows
to specify a custom limit. Developers can then increase this limit
locally for their debugging sessions.
R=clemensb@chromium.org
Bug: chromium:1380561
Change-Id: Ie65a47d49e9ca1d8b05617df0f46c187afef06e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027963
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84417}
Global/traced handles are only ever used with two callbacks:
* MarkCompactCollector::IsUnmarkedHeapObject
* IsUnscavengedHeapObjectSlot
IsUnscavengedHeapObjectSlot already works with shared heap objects
because it only applies to objects in the young generation.
This CL fixes MarkCompactCollector::IsUnmarkedHeapObject with shared
heap objects. E.g. a local GC isn't allowed to load markbits for
shared objects.
Bug: v8:13267
Change-Id: Id0fb9ed73409e384eed4c7168100a1bf40a06f94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4044362
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84414}
... instead of computing them on the fly. This approach seems to
perform slightly better because it requires less code.
Bug: v8:7703, v8:11460
Change-Id: If31a06fbc748251c491c011e9e3f118665e20159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020456
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84413}
With shared space (instead of the shared isolate), the AccessorInfo
implementation of SharedArray's length property is no longer threadsafe.
Until AccessorInfos can be put into shared or RO space, go back to
storing the length field as a per-instance in-object field, which is
unfrotunately a little wasteful.
Bug: v8:12547
Change-Id: I99c1cbf26047da48a4b4c11e14ab7def7d4e4f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4039309
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84408}
Clear OLD_TO_SHARED slots in free memory after shrinking large objects.
This CL now clear all slots outside of the object and not just from
the next OS page boundary.
Since we are already here also stop clearing OLD_TO_NEW and OLD_TO_OLD
since they should already be cleared at this stage of the GC. Add
DCHECKs that this always holds. We also don't need to iterate large
code objects since we do not shrink such pages anyway.
Bug: v8:13267, chromium:1385717
Change-Id: I75f6e56a7c13974ce669bbba29262e95eb94d287
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4037981
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84407}
Currently, if a script is compiled on the main thread or deserialized on
any thread, and a matching Script object is found in the Isolate
compilation cache, the new content is merged into the existing Script.
This CL implements the same merging for scripts which were compiled by a
background task. I expect speed changes to be minimal, because merging
is only needed in a small minority of compilations. When needed, it
usually takes about 10% as long as the deserialization of the script,
which in turn is faster than compilation from source text.
This CL also removes some code which I added in preparation for merging
on a background thread in this case. Upon further discussion, we've
determined that the extra round trip to a background thread when the
main thread is likely just waiting for completion would do more harm
than good, and performing the compilation cache lookup from the
background thread would be quite cumbersome.
Bug: v8:12808
Change-Id: Ia7a14a739779ab658b505572d19df4ec489a078e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023904
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84402}
The gap resolver issue that this was blocked on is fixed now.
R=clemensb@chromium.org
Bug: chromium:1269989
Change-Id: I1aa4566190dd9705bf5688f5c551923f6273f93e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042243
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84398}
This CL implements Torque builtins for BigInt left shift and right
shift and truncates shift operations when the shift amount is a
constant.
- Propagate truncation if we know the operation is a left shift.
- Lower the operation to a word64 right shift if the lhs is Signed- or
UnsignedBigInt64 and we know the op is a right shift.
A side effect of truncating left shift is it will not throw a
BigIntTooBig exception in optimized code.
Bug: v8:9407
Change-Id: Ibd42cf897ef8a35f6addd09674faf409654d6d7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4028142
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84396}
Otherwise we may pass an out-of-bounds type to {IsSubtypeOf}.
Bug: v8:7748, chromium:1388938
Change-Id: Ifcbf31c68da40d7b7a365c9d756cd5fa81347291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040930
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84395}
The interpreter does not implement WasmGC, hence always use Liftoff as
reference if WasmGC opcodes are enabled.
R=manoskouk@chromium.org
Bug: v8:13496, chromium:1387316
Change-Id: I29f496ebc1921c727c216dda763c1e9a63d6597b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042288
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84392}
The test fails with multiple isolates because with the NativeModule
cache the second isolate can create an unexpected state for the first
isolate.
R=clemensb@chromium.org
Bug: v8:13503
Change-Id: Ic83d374c61703fdeb570b65b3c444ab0ae3cef8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040929
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84391}
This adds an implementation for the {kRef} case in
{MakeDefaultArguments}.
R=jkummerow@chromium.org
Bug: v8:13496, chromium:1391168
Change-Id: I4c0e85b46c50f766816f799e80cf1afbe6fa258a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4042663
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84386}
1) Pass {WasmFeatures} by value, it's a single word.
2) Pass a {base::Vector} instead of {start} and {end} pair.
3) Remove a redundant constructor (just pass an empty wire bytes vector
instead).
R=thibaudm@chromium.org
Change-Id: I337c3c86960505ae23c88cb6adc5646a61111f76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4030434
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84382}
This adds a regression test for https://crrev.com/c/4025548.
Using {addBodyWithEnd(body)} makes the test a lot faster, and we just
skip it on known-to-be-slow variants.
In a default release build, the test takes ~0.3 seconds. In an x64 debug
build, it takes 17 seconds.
Bug: v8:13436
Change-Id: I63e2927774601b24d177b03cf075f9a8d287e934
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4031206
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84371}
