LoopUnrolling and LoopPeeling are already used for Wasm, so they it
makes not sense to keep the flags experimental for JS.
As for turboshaft-machine-lowering-opt, it should soon be enabled by
default, so remove the experimental status also makes sense.
Bug: v8:12783
Change-Id: I6ac8b58c0aa395859ad7a29fb387e9daaf1db66b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5185037
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91773}
This is a reland of commit b4ad5c2eff
The failing DCHECK on non-ptr-compr builds has been turned into an
if condition to correctly handle this situation. This is simpler than
the alternative of moving these checks into all callers.
Original change's description:
> [sandbox] Assert no trusted space objects are passed into CompareRoots
>
> As we're moving more objects into trusted space, we need to be careful
> when comparing such objects against objects inside the main cage, in
> particular to roots (which happens frequently). This is because by
> default, such comparisons would be 32-bit comparisons of just the lower
> 32-bits of the address, which is no longer correct once the objects live
> in different pointer compression cages. In C++ we have DCHECKs to catch
> these cases. This CL adds a similar debug assertion into generated code.
>
> Bug: chromium:1473677
> Change-Id: Iaae496b6ed20d7bec88923e8d70e27cb41b9e336
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5181094
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91763}
Bug: chromium:1473677
Change-Id: I4e0c8da75cf1172dbfe0a12850772ff9bcb768e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5185495
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91768}
This adds use counters for six Wasm proposals where we tracked usage but
never populated use counters with that data.
In order to avoid the same mistake in the future we also add static
asserts to check that any staged or shipped feature has a corresponding
use counter.
The chromium-side wiring will be done in a follow-up.
R=jkummerow@chromium.org, mlippautz@chromium.org
Change-Id: Id44911a80e61ec85b0cd700cd3eba4e229f310d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180775
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91766}
Because of compiler limitations with the flexible array member
extension, in particular around subclassing, introduce a new macro which
defines the flexible array members. This also requires accessing
flexible array members using a macro, rather than with offsetof.
Bug: v8:12710
Change-Id: Ibf8ae9b20bb1a83be7374e439bff484914d7bad1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5148173
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91765}
This reverts commit b4ad5c2eff.
Reason for revert: Breaks some builds: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20no%20pointer%20compression%20debug%20builder/8710/overview
Original change's description:
> [sandbox] Assert no trusted space objects are passed into CompareRoots
>
> As we're moving more objects into trusted space, we need to be careful
> when comparing such objects against objects inside the main cage, in
> particular to roots (which happens frequently). This is because by
> default, such comparisons would be 32-bit comparisons of just the lower
> 32-bits of the address, which is no longer correct once the objects live
> in different pointer compression cages. In C++ we have DCHECKs to catch
> these cases. This CL adds a similar debug assertion into generated code.
>
> Bug: chromium:1473677
> Change-Id: Iaae496b6ed20d7bec88923e8d70e27cb41b9e336
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5181094
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91763}
Bug: chromium:1473677
Change-Id: I6f56bbb2402a263ec4e8449f76e4145708b57377
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5185036
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91764}
As we're moving more objects into trusted space, we need to be careful
when comparing such objects against objects inside the main cage, in
particular to roots (which happens frequently). This is because by
default, such comparisons would be 32-bit comparisons of just the lower
32-bits of the address, which is no longer correct once the objects live
in different pointer compression cages. In C++ we have DCHECKs to catch
these cases. This CL adds a similar debug assertion into generated code.
Bug: chromium:1473677
Change-Id: Iaae496b6ed20d7bec88923e8d70e27cb41b9e336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5181094
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91763}
The wasm-to-js counter was introduced to detect and prevent the
accidental capture of JS frames. This was needed before, when JS frames
could be pushed alongside wasm frames in a secondary stack.
But this can be simplified now by relying on the central-stack switch:
the suspender contains JS frames if and only if it has switched to the
central stack and has not returned yet.
Rename the counter to "has_js_frames", make it a boolean, and update
this boolean when switching to/from the central stack.
R=jkummerow@chromium.org
Bug: v8:12191
Change-Id: Ic541afcefecf3776323701aec64f935988b2e38e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180774
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91761}
Using the same path for DEPS'ed and previously checked-in files
causes conflicts when going back and forth between new and old
revisions. Since all references here are v8 stand-alone, the
exact location shouldn't be important. Therefore we use some
new name to avoid conflicts when locally running `gclient sync`.
Bug: chromium:1513046
Change-Id: Icf1ecc4d9b1f9c7e67b5a542c2be08ff9738d045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184217
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#91760}
When the trap handler is used, out of bounds checks are implicit and
happen during the access, the alignment runtime check is explicit.
However, without the trap handler we first checked for oob and then
for the alignment causing a different error message for atomic
operations that trap both for oob and unaligned access causing
inconsistencies / observable behavior differences between liftoff and
Turbofan / Turboshaft.
This CL fixes these inconsistencies for all atomic operations by
always first executing the alignment check and then the (implicit or
explicit) bounds check.
Change-Id: I98fc37a334fbf70500b0c8b7a768561db3c1b977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180367
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91759}
This allows load elimination to eliminate repeated loads of the table
in case of accessing multiple values or multiple tables.
Note that this is for non-funcref tables only (for now).
Bug: v8:14034
Change-Id: I492062567526e1c2e5a001fa0643632b54884a1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180776
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91758}
TypedArray lengths can be larger than Uint32 on 64-bit arch, so we need
the value representation to be IntPtr rather than Uint32. Change Maglev
to have an IntPtr representation instead of a Word64 one, and use this
for TypedArray length checks.
Bug: v8:7700
Change-Id: I8c1fa227f4568aa98e32516f0bbf2dc9561404ec
Fixed: chromium:1516871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184218
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91756}
Counters for incremental marking (start time, duration, bytes) used to
reside in GCTracer. This was fine as long as only full GCs used
incremental marking.
MinorMS also uses concurrent marking and may update these counters.
Specifically, due to interleaved sweeping, a concurrent MinorMS may
override the incremental marking time of a previous full GC, which will
result in negative incremental marking duration when finalizing the full
GC (i.e. after sweeping).
This CL fixes such issues by moving the cycle specific counters to
GCTracer::Event.
Bug: v8:13012
Change-Id: I055831fb831dfd3c06a3d3897d902afbfd59b3b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184216
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91754}
1) Delay crash due to ineffective full GCs until after trace-gc output
for the current cycle.
2) Mark interleaved GCs in trace-gc output (to make it easier to
identify them in the future).
Change-Id: I6d30bd83581d1ec037e90c926adab72a25024799
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184215
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91752}
This is a *partial* reland of commit 2e671bb003
This CL contains only the fix for 1) below.
Original change's description:
> [heap] Fix OOM in new space allocations
>
> This CL fixes 2 issues:
> 1) OOM when new space is empty because old space is full. Old space size
> should only be considered for allocating pages beyond capacity. As
> long as new space capacity is below the limit, allocation should
> succeed.
> 2) OOM crash before trace-gc output. This makes it appear as if the OOM
> comes from a minor gc when it is actually a full gc.
>
> Bug: v8:12612
> Change-Id: I9f072e1e3cdc1d8ffbf52d1153f6dfc5bc1dd4c8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176936
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91734}
Bug: v8:12612
Change-Id: I98f8539e7faee4dd263e54fde1d6efd428fad039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5184135
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91750}
Every time we inline a function with argument count different than
the parameter count, we retain all arguments (up to the parameter
count) twice in the deopt translated state.
In the CL, we remove the duplication.
Change-Id: I3de637dfeecad759328183ed369ac96e7c89ea98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4714609
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91749}
Instead of copying the build logic from gm.py call it.
This should now make gen-static-roots.py use reclient when available.
Fixed: v8:14538
Change-Id: I309e5255bb76253f2f22551a3455a00fd377469e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180370
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91742}
__builtin_trap() could potentially emit `cite` on s390x which
crashes with SIGFPE instead of a breakpoint trap.
This CL fixes the issue on both ppc64 and s390x by emitting
the `bkpt` instructions.
Change-Id: I31d7881da1b50ee193b942e3ec2b4960991352f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176785
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#91739}
This reverts commit 2e671bb003.
Reason for revert: flakes on multiple bots
Original change's description:
> [heap] Fix OOM in new space allocations
>
> This CL fixes 2 issues:
> 1) OOM when new space is empty because old space is full. Old space size
> should only be considered for allocating pages beyond capacity. As
> long as new space capacity is below the limit, allocation should
> succeed.
> 2) OOM crash before trace-gc output. This makes it appear as if the OOM
> comes from a minor gc when it is actually a full gc.
>
> Bug: v8:12612
> Change-Id: I9f072e1e3cdc1d8ffbf52d1153f6dfc5bc1dd4c8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176936
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#91734}
Bug: v8:12612
Change-Id: I052913a6e124b45363edc25dd0da302952e36626
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180738
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#91738}
The alignment check is redundant if the access size is 1. Turboshaft and
TurboFan optimize out the code later, but Liftoff emits this useless
sequence:
[ alignment check
0x2b9e02b5a8a6 a6 8bfb movl rdi,rbx
0x2b9e02b5a8a8 a8 83e700 andl rdi,0x0
0x2b9e02b5a8ab ab 85ff testl rdi,rdi
0x2b9e02b5a8ad ad 0f8574000000 jnz 0x2b9e02b5a927 <+0x127>
]
This CL avoid emitting the alignment check for single-byte accesses
in all compilers. This will save memory and compile time also for the
optimizing compilers.
R=dlehmann@chromium.org
Change-Id: I8ca9719248113cf57fd3a34dc0c70180613d4872
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5177987
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91737}
Unify the deopting and non-deopting Load/StoreTypedArrayElement by
making the detached check a separate node. This allows us to
a) Potentially eliminate the check if we've already checked earlier
and there have been no side effects,
b) Check for detached _before_ loading the length, in case some future
code using that no-longet-valid length could have caused trouble.
Bug: v8:7700
Change-Id: I12d390d12fbd3215f781077cc23ca4c8fc783323
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176948
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91735}
This CL fixes 2 issues:
1) OOM when new space is empty because old space is full. Old space size
should only be considered for allocating pages beyond capacity. As
long as new space capacity is below the limit, allocation should
succeed.
2) OOM crash before trace-gc output. This makes it appear as if the OOM
comes from a minor gc when it is actually a full gc.
Bug: v8:12612
Change-Id: I9f072e1e3cdc1d8ffbf52d1153f6dfc5bc1dd4c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5176936
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91734}
The CL replaces the current way of handling free pages - concurrent
unmapper - with a page pool. The latter is very similar to what
Oilpan already uses. The pages are kept alive until a memory-reducing
GC kicks in, after which they get released.
The downside of removing the offloading logic is that the large,
executable and trusted pages are now sequentially freed, which may
in theory introduce regressions in rare scenarios.
Benchmarking:
- Jetstream2:
- M1: +0.3%
- Windows: +2%
- Speedometer2:
- M1: +0.3%
- Windows: +0.2%
Bug: v8:14390
Change-Id: I520ae79a5942cf9411667089bfaf3b4df9973270
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5033402
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91733}
Tested with lldb-vscode. It is currently incomplete and slow, but
it allows expansion of V8 objects, and then expanding their children.
Also adds a stack trace visualization to the isolate, from which
you can expand frame summary objects or the expression stack.
Bug: None
Change-Id: I9473383e00f69f57c1e1bc7a7348e96ae4257724
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4952335
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91732}
We extend the use of trapping null to the Liftoff compiler. The
following operations now use trapping instructions instead of explicit
null checks when possible:
struct.get/set, array.get/set/len, ref.as_non_null.
Drive-by: Fix the protected-instruction offsets returned by the
liftoff assembler on arm64.
Bug: v8:14034
Change-Id: Ie090feb5fdf12e69c2ce670b408d9d023f3a274d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5173423
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91731}
Instead of emitting layout asserts in generated *-tq.h and *-tq-inl.h
files, which might get forgotten and get pulled in for every use of
those headers, emit them in *-tq.cc files. This has two advantages:
1. They are no longer opt-in, so _all_ types with both torque and C++
layouts get asserted (this caught a bug in BytecodeArray!)
2. They no longer need to be templated, because they're not being
defined before the object definition. This will surely make the
compiler happier.
Bug: v8:12710
Change-Id: I630495739c422e1ba89ce78cb218379d858f54cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5163948
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91730}
Improve comment around CHECKs in non-allocating prefinalizers and add an
additional CHECK for the same invariant.
This does not fix any issue but would merely introduce a well-defined
crash in case we get no-allocation scopes wrong.
Bug: chromium:1516773
Change-Id: I753d16361f83f47256433eef4b8e79412bf78a62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5180366
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91727}
