This enables an optimization for JavaScript which is currently only
enabled for WebAssembly. Clusterfuzz found problems on a previous try to
enable this (see https://crbug.com/1356461), but a fix
(https://crrev.com/c/4197349) landed in the meantime which might have
fixed things.
Any resulting crashes or other issues will have to be fixed before the
v11.2 branch cut, otherwise we will have to revert this CL.
R=jkummerow@chromium.org
Bug: v8:13581
Change-Id: I139804e53285803d7f2178893c86b520c96a8eb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205923
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85565}
It's much more likely to find the code object in CODE_SPACE than in LO
space (or the THIRD_PARTY_HEAP). Also, remove an obsolete and misleading
comment.
Bug: v8:13654
Change-Id: Ia6c2a28a8eb5b0fb3f5951a9018fac0c0683a96e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205914
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85564}
Calling EnsureFinished could sweep array buffers without first making
sure that promoted page iteration is done.
Bug: chromium:1411076
Change-Id: Ic6cb9b13af0851f40c8720f046602a7739aa0efa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205922
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85563}
.. and replace it by base::Optional<Code>. It's no longer needed, now
that Code and InstructionStream cases are merged.
This was trickier than it sounds at first, because:
- CodeLookupResult (CLR) was used during the MARK_COMPACT GC phase and
thus had to observe subtle semantics in the presence of
forwarding pointers.
- CLR implicitly contained a Code object for off_heap_trampolines
and an InstructionStream object for everything else. These implicit
behaviors threaded through elsewhere, e.g. in the
inner-pointer-to-code cache which relies on the fact that the
underlying object pointer does not move until GC completes and
the cache is flushed.
- Semantics of the dual-object {Code,InstructionStream} are generally
very subtle during GC.
This CL attempts to make all this more explicit by introducing a
GcSafeCode wrapper type which must be used in code that is affected
by semantics described above. The GcSafeCode type exposes only methods
that are safe to call during MARK_COMPACT.
Drive-by:
- Rename the Heap::GcSafeFoo function family s.t. a 'GcSafe' prefix
means that the function can be used during GC and returns
GcSafeCode objects; and 'TryFind' vs. 'Find' returns a
base::Optional<Foo> vs. just Foo.
Bug: v8:13654
Change-Id: I410b5539ea1b584b823bce2dafd8d1328eedc039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203385
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85562}
This CL adds a new Turboshaft reducer that is suitable for changing the
graph in a way that doesn't reduce individual operations, rather changes
the structure of the graph. The first such reduction we support is
transforming if-else cascades that check if a given value is equal to
any constant from a given set into a switch with cases corresponding to
the constants in the set.
Bug: v8:12783
Change-Id: Iee1e5581a334c3dc255d673d2178f76706e6dae2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4106752
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85561}
MinorMC only promotes whole pages, but doesn't move any objects. Thus
there is no need to update specific pointers. The update pointers phase
in practice only filters for objects that were promoted.
Since marking anyway needs to filter the remembered set (because slot
may be overwritten), we can just filter the remembered set once there
instead of doing it twice (i.e. end of evacuation and the following
marking phase).
Updating the external strings table remains as is since it is used by
heap verification as well.
Bug: v8:12612
Change-Id: I7e36e8acb886852087d303eceec4276f5349b272
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205907
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85558}
In memory reducing GCs, promoted page iteration is not delayed and thus
pretenuring feedback is available earlier.
Bug: chromium:1411113
Change-Id: I3140b0bbcb9bfa537def5faac9ddd07183668498
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4204030
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85557}
Adding case equivalents requires a canonicalized character range.
With unicode sets we missed to canonicalize ranges before adding case
equivalents in two locations.
Bug: chromium:1410963
Change-Id: I5907062f8c29b6e9d4a4c8166d3af05079298c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205912
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85556}
- Mark run_perf.py executable
- Add more user-friendly option --d8-path aliase
- Add --repeat alias that matches the go/crossbench flag
- Handle symlinks for d8-directory using pathlib
- Only print timeout message if the result has timed_out == True
- Add .DS_Store to gitignore
Change-Id: Ia0fb0b926632af4b520d3aaf447e5bd35723816e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205910
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85555}
Originally this was a condition (not a DCHECK) guarding against OSRing
into self-hosted JS builtins, which no longer exist since 2016. After
various refactors, our assumption was that this could no longer
happen, and we changed the condition into a DCHECK.
However it appears that we still have non-user-JS functions that can
reach TrySetOsrUrgency as part of extensions, e.g.
--expose-externalize-string; but I can't think of a reason not to OSR
these.
Let's try removing the DCHECK.
Bug: chromium:1410985
Change-Id: I2698eac4cecbf5aa33775c0217c2f69a3c96323a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205909
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85554}
Rolling v8/build: c6df5bb..ddbdf3a
Rolling v8/buildtools: 3c7e3f1..7a0617e
Rolling v8/buildtools/linux64: git_revision:5e19d2fb166fbd4f6f32147fbb2f497091a54ad8..git_revision:629f6be82956987c7ac10faf2acf0534b1667fa2
Rolling v8/buildtools/third_party/libc++/trunk: 1127c78..b93c728
Rolling v8/buildtools/third_party/libc++abi/trunk: d520d58..b74d771
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/35d0649..5ba838f
Rolling v8/third_party/depot_tools: b7d8efd..94b0eb1
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230129.1.1..version:11.20230129.3.1
Rolling v8/tools/clang: c272f2c..527cfbb
Rolling v8/tools/luci-go: git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7..git_revision:c41d94e382727fc5276cd2771741990543fce337
Rolling v8/tools/luci-go: git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7..git_revision:c41d94e382727fc5276cd2771741990543fce337
Change-Id: I91cb3fdbcd092a84ff68a2ef261752e1ff0f65c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205882
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85553}
Port 76a817e03a
Original Commit Message:
This fixes a TODO about atomics and memory64 and removes the explicit
CHECK that checks for the unsupported situation.
Similar to other memory accesses, the memory index is supposed to be a
64-bit value if memory64 is being used.
The bounds checking implementation in Liftoff and TurboFan is shared
with non-atomic memory accesses, so this is already prepared for
memory64. We only need to fix the expected type in the function body
decoder, and prepare the assembler for 64-bit values.
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I61bb3106c9661f7b8aa72b27ed439a8d94890192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4204353
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/main@{#85552}
With shared objects we can't get the isolate from the heap object, so we
need to pass the isolate as an argument.
This CL plumbs the Isolate through the following set of methods on
JS{Object,Receiver}:
- SetIntegrityLevel
- TestIntegrityLevel
- PreventExtensions
- IsExtensible
Notably it does not touch the same methods on JSProxy, because JSProxies
are never shared.
Bug: v8:12547
Change-Id: I24fcf4b7f9f9d72218ff1f386c34577912a93be1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4204828
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85551}
With concurrent promoted page iteration, the parallel evacuation phase
merely pushes the pages to the sweeper. Therefore, the work is minimal
and there is practically no justification to start a parallel job for
it.
Bug: v8:12612
Change-Id: I585d9e23e07b70fa780239bd26843530c6ca69a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203376
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85550}
CheckMaps with migration can (and is expected to) mutate fields and maps
on migration, which means it cannot be considered to be
non-side-effecting in terms of writes.
This allows us to revert crrev.com/c/3998653, as we should now correctly
insert a dynamic map re-check after a potential map migration.
Bug: chromium:1380063
Change-Id: I28f78f0579529279b4c3810fabbd2edb653a6f1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203379
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85549}
1) Eliminate scopes for ContributeToSweepingMain when there is no work
to do.
2) Get all swept pages in a single lock instead of lock per page.
Bug: v8:12612
Change-Id: I41ee0aa196327f6a61c698164ff3126527c6113b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197353
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85548}
The script ablation study was never pushed to stable.
The preliminary numbers showed non-monotic behavior for high-level
metrics for initial script delays < 250ms.
Depends on code removal in chrome: https://crrev.com/c/4189106
Bug: chromium:1193459
Change-Id: I96540937768566d243a1bfd94234c3dd1b35a77d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188389
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85547}
Returning a pair instead of writing to two output parameters avoids a
number of memory writes in the unrolled LEB-decoding slow path.
Instead of writing to the length and result pointer after each byte, we
now only write once at the very end.
This makes the LEB decoding slow-path ~30% faster locally (but we do not
spend much time in that function overall for most modules).
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: I02baeb0eb4620c46ba0babbc32bb6ac087887d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200633
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85546}
Stack merging must always happen from the "current" state. Thus remove
the `source` argument to `MergeFullStackWith`, and implicitly use
`cache_state_`.
Note that `MergeStackWith` already does the same.
R=jkummerow@chromium.org
Change-Id: I501182e764e60edcb4f6ebf33b9863e652bf3875
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203374
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85544}
We've long had a custom v8::internal::BitVector implementation, which
is functionally equivalent to a Zone-allocated std::vector<bool>. As
part of the effort to move away from Zone-allocated std::vector, this
patch replaces all uses of ZoneVector<bool> with BitVector.
Since both implementations use a "one bit per value" strategy, no
significant changes to performance or memory consumption are expected.
There may be some speedups due to replacing std::vector bounds checks
with DCHECKs.
Change-Id: I63dbee071767c91cb416c856e1f8090533b76470
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203368
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85543}
The memory64 implementation should be feature-complete and safe to use.
Stage it (enabled via --wasm-staging) to enable fuzzing and find
missing cornercases.
R=ecmziegler@chromium.org
Bug: v8:13692
Change-Id: If585115ec4d101b4192a3f3ebfc302ee24e16cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200643
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85542}
We were sometimes passing a `VarState` reference plus a stack offset,
but the stack offset was always the same as encoded in the `VarState`.
Thus drop that additional parameter, and just get the offset from the
`VarState`.
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: Ic75946890d36c909c557ad44fe55f552e25d169a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200645
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85541}
This test is unsuitable for "GC stress" mode, because it interferes with
the execution of FinalizationRegistry cleanup tasks when asynchronous GC
is used. By mistake it was ommitted from crrev.com/c/4197675.
Bug: v8:13257
Bug: v8:13699
Change-Id: I81549cee7fae988aaa23611041d722f2e6abd89f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200635
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85540}
The memory access immediate consists of two LEB-encoded integers. Both
are mostly single-byte values. Hence add a fast path that checks for
that, and avoids the general LEB-decoding logic otherwise.
This saves a few dynamic branches, in particular it is independent of
the {memory64} flag.
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: Iee981dd451f8acb001aa36f1dd3c8103839d01aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198137
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85538}
.. which are invalid now that AbstractCode is either a BytecodeArray or
Code object.
Bug: v8:13654
Change-Id: Ib6c396c05dae9db5a6775cfc6e2897ec42236ec6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200641
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85537}
The code still mostly refers to semi spaces when computing sizes.
This will be renamed at a later date.
Bug: v8:12612
Change-Id: Ib8f972493332425e971a35b0b892630a627810c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188382
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85536}
Rolling v8/build: 6971fa8..8aeec71
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2ba5bfe..cae097a
Rolling v8/third_party/depot_tools: 562481d..b7d8efd
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230126.1.1..version:11.20230127.1.1
Rolling v8/third_party/zlib: 44d9b49..2d44c51
Rolling v8/tools/clang: 1214b4d..c272f2c
Change-Id: I3ce7a03da15325f397552f0335a5e68acf5226b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200978
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85528}
ppc/s390 use separate instructions for signed/unsigned comparisons
in order to set flags. We need to be able to differentiate between
these two types in order to emit the correct instruction.
Change-Id: Ia1b4508994c6e21a7d86ab070234eb37f76aca29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198317
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#85527}
This fixes a TODO about atomics and memory64 and removes the explicit
CHECK that checks for the unsupported situation.
Similar to other memory accesses, the memory index is supposed to be a
64-bit value if memory64 is being used.
The bounds checking implementation in Liftoff and TurboFan is shared
with non-atomic memory accesses, so this is already prepared for
memory64. We only need to fix the expected type in the function body
decoder, and prepare the assembler for 64-bit values.
R=jkummerow@chromium.org
Bug: v8:13636, v8:10949
Change-Id: I210ac488bd2bb1cb141e16597ca62d3fb27cad3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191767
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85525}
This adds a few annotations and minor optimizations to improve
performance of decoding and Liftoff compilation.
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: Icf582d72c35db68228bcecea0a8c2ab3f8f0d340
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198138
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85524}
So we can statically find the returning type in case of a Smi.
Bug: v8:7700
Change-Id: I67f8d1c1c96fef8dc4e246953d9face2c04a9923
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198152
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85523}
Threads that are waiting for promoted page iteration to finish can
contribute by iterating themselves.
This should allow array buffer sweeping to start earlier.
Drive-by: encapsulate local pretenuring feedback and local old_to_new
remembered sets in a container for easier sharing and passing around.
Bug: v8:12612, chromium:1407652
Change-Id: I4bf9402191886413b7bd25e2e8c038fc9fc28437
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4184204
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85517}
