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}
We should not re-use the HeapNumber from the loaded source object,
we must allocate a new one.
Bug: v8:7700
Change-Id: I6776356449623383a129d2bbe2b7f0ff9171748e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198148
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85515}
This CL fixes failing DCHECKs when Heap::CollectCodeStatistics() is
invoked in the atomic GC pause.
* Heap::CollectGarbage disallows GC, so move CollectCodeStatistics()
into Heap::GarbageCollectionEpilogue() where such an exception
already exists.
* CollectCodeStatistics() also needs to finish sweeping but a DCHECK
in GCTracer only allowed this for heap verification.
Bug: v8:13267
Change-Id: I6c8e75ad5e78347fc162d3b67be10cb972269a12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197335
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85513}
31 out of the 36 JS tests in test/mjsunit/harmony/weakrefs/ rely on
precise GC with the following general pattern: they allocate some
objects, clear all references to them, invoke a GC, then perform
some test that assumes that the GC has reclaimed the objects.
When conservative stack scanning is used, this may fail.
This CL fixes the tests, ensuring that a precise GC will be invoked
when necessary, without scanning the stack. To achieve this, the GC
has to be invoked in asynchronous execution mode, which ensures that
it will be invoked from the event loop without a stack. In some
cases, this change requires a non-trivial change in the tests.
In 5 tests, part of the test's objective was to verify that a weak
reference is not cleared before the end of the turn. In those, it
was not possible to invoke GC asynchronously, as this would
immediately start a new turn. These tests still use synchronous GC
and they have been modified, if necessary, to allow for CSS (i.e.,
to not test that all possible garbage is reclaimed after a
sequential GC). Because of CSS, these tests may not always test
everything that they were intended to.
Some tests are unsuitable for testing in "GC stress" mode, because
this interferes with the execution of FinalizationRegistry cleanup
tasks or with the clearing of WeakRefs, when asynchronous GC is used.
Tests with trivial fix:
- cleanup-from-different-realm
- cleanup
- cleanup-proxy-from-different-realm
- cleanupsome-2
- cleanupsome-after-unregister
- cleanupsome
- finalizationregistry-keeps-holdings-alive
- multiple-dirty-finalization-groups
- stress-finalizationregistry-dirty-enqueue
- undefined-holdings
- unregister-after-cleanup
- unregister-before-cleanup
- unregister-called-twice
- unregister-inside-cleanup2
- unregister-inside-cleanup3
- unregister-inside-cleanup
- unregister-many
- unregister-when-cleanup-already-scheduled
- weak-cell-basics
Tests with non-trivial fixes; same logic but very restructured:
- cleanup-is-not-a-microtask:
- cleanup-on-detached-realm
- finalizationregistry-scheduled-for-cleanup-multiple-times
- finalizationregistry-independent-lifetime
- finalizationregistry-independent-lifetime-multiple
- reentrant-gc-from-cleanup
- symbol-in-finalizationregistry
(was 2nd part of former symbol-as-weakref-target-gc)
- weak-unregistertoken
Tests with non-trivial fixes; same logic, restructured, using
synchronous GC:
- finalizationregistry-and-weakref
- symbol-as-weakref-target-gc
(was 1st part of former symbol-as-weakref-target-gc)
- two-weakrefs
- weakref-creation-keeps-alive
- weakref-deref-keeps-alive
This is a reland of commit 20a954f4bc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191774
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85477}
Bug: v8:13257
Bug: v8:13662
Change-Id: I298ccbc932afc44d5c8c858620a180388a25f5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197675
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85512}
The bazel version 5.4.0 (LTS) changes the defaults how python
stub scripts are chosen, which fixes a problem using Python2 scripts
on systems with no Python2 available.
This was uploaded as follows:
cd tools/bazel
cp <path-to>/bazel-5.4.0-linux-x86_64 ./bazel
upload_to_google_storage.py -b chromium-v8-prebuilt-bazel/linux bazel
Using:
https://github.com/bazelbuild/bazel/releases/download/5.4.0/bazel-5.4.0-linux-x86_64
Bug: chromium:1410471
Change-Id: I8e15cf2b42f77133206d6f5b789dab1f7c336f3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198145
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85511}
Rolling v8/build: 1015724..6971fa8
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/6cfc140..2ba5bfe
Rolling v8/third_party/depot_tools: 44e9bee..562481d
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230125.2.1..version:11.20230126.1.1
Rolling v8/third_party/zlib: dca2b91..44d9b49
Rolling v8/tools/clang: 566877f..1214b4d
Change-Id: I8d3f4ead3aff2bb32641476bd01a97ec0e67524c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197939
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@{#85509}
Some very hot getters in Blink can spend many cycles on decompression.
We're planning to optimize such paths by selectively using uncompressed
pointers.
Change-Id: I78af751c423c56010a794448450032c66f8fa244
Bug: chromium:1410145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191778
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85508}
Drive-by: Simd128 load and store ops are also grouped
within a macro.
Change-Id: I7bfefb858472a1dfa6ed7e0615114b57739b1a85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4193366
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#85507}
We accidentally merged the static_type of the node into the runtime
info, rather than the runtime type we wanted to use.
Bug: v8:7700
Change-Id: Ief2f4887178a1b1f506a6a8b8be4d010a26eb92f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197352
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85503}
Other optimizations can create a situation where it is valid to treat a
stack slot as either 32-bit (which is what its value was created as) or
64-bit value (to which it was implicitly zero-extended). So when moving
such a value to a register, we cannot use a 32-bit move instruction just
because the source was annotated as such; we must also take the target
slot's representation into account.
Fixed: chromium:1407594
Bug: chromium:1356461
Change-Id: I00d850c11a020b055e90f6107b604cdd267d9b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197349
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85501}
In translation arrays, the most common opcode is
MATCH_PREVIOUS_TRANSLATION. It is usually represented as two bytes: one
byte for the opcode, and a second byte for how many instructions to
match. In rare cases, it could extend to a third byte or further due to
the variable-length encoding of the operand.
In this change, I propose a more compact encoding for
MATCH_PREVIOUS_TRANSLATION instructions. The encoding described above is
still valid, but the decoder will also look for another option: if the
opcode byte's value is greater than any real opcode, then the opcode is
implicitly MATCH_PREVIOUS_TRANSLATION and its operand is equal to the
opcode byte minus kNumTranslationOpcodes.
This change saves about 10% of the total TranslationArray size in an
Octane run (130 kB). I don't see any speed changes in encoding
(based on V8.TFCodeGeneration) or decoding (based on
js-perf-test/StackTrace).
I recognize that we're reaching the point where continuing to fiddle
with TranslationArray encoding yields diminishing returns, but the
complexity introduced by this change is well encapsulated (within two
functions in a single .cc file), so I think it's worth doing. I don't
plan any further changes.
Another option I considered for packing data into the opcode byte is
at https://crrev.com/c/4190521 . Its benefit is greater than this
change, but its complexity is too, especially in the decoder.
Bug: v8:11354
Change-Id: I02fd4dc5f631e54f7a7acc483fbe82ceb5a9ccf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4190523
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85500}
We need them there due to how they are restored on resume, but don't need them at all for other loops.
Bug: v8:7700
Change-Id: I28a13ccf05d4fcd7bcf5fb8abef4dedd64f990f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197096
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85498}
Fixes running gen-static-roots for:
* debug builds: need to access the value unchecked when generating the
table as the shared r/o root table is uninitialized.
* different architectures: to generate the static-roots.h file we must
have the same predictable heap layout in mksnapshot as in the actual
static roots enabled build.
Bug: v8:13466
Change-Id: I87e087987d735bf3368085db2e977542978a88e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194204
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85497}
