- 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}
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}
