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}
This removes the `direct_input` option from `CloneAndInlineBlock`,
which is now unnecessary thanks to the fix in
https://chromium-review.googlesource.com/c/v8/v8/+/4191773
In addition, this simplifies the code of `CloneAndInlineBlock` by
reducing the usage of assembler-global variables and by moving the
phi logic into the same function.
The creation of variables is now controlled by `current_block_needs_variables_` alone. To set this remaining global flag in a scoped fashion, this also adds the helper class
`ScopedModification` (which is used to simplify `ReentrantScope` too).
Bug: v8:12783
Change-Id: I979b110ea10921477efc4bf2c38bd56b5c573442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194203
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85496}
Maglev's regalloc currently fills up registers with values it has on any
side of a branch; pulling the value from the stack on the other side.
This causes values that are live at the end of loops to be unspilled
before loops if they weren't already in that register. This is never
useful.
Bug: v8:7700
Change-Id: I120f3b351ea9919e450f8528a118191692e8cffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4197337
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85494}
This is useful to have cross-platform conditional jumps.
LiftOff, Sparkplug and Maglev all contain their cross-platform
condition that we cast/convert back-and-forth to the architecture one.
This unifies names (as alias) and avoids the back-and-forth.
The CL only adds the conditions, it does not use them yet.
Bug: v8:11461
Change-Id: I79a71bd7fa9d11903c9722fccde239eb3da8dba9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194731
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85490}
Since --shared-space is now enabled by default, we don't need this
flag for testing anymore.
Bug: v8:13267
Change-Id: Ib4c1111a75dbf93d05ccf3bac752c0ef089e3c15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194715
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85488}
Previously we stored kProxy in this case, which resulted in
set semantics for proxies.
Bug: chromium:1409294
Change-Id: I6cca772eb6e6a35944375a72d10fc279263d2094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188383
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#85487}
With https://crrev.com/c/4166369 the default names changed from
e.g. libv8.so to lib_v8.so.
This causes at least some issues on build bots but might also
impact other projects assuming certain names in case of component
builds.
The default naming can be prevented by providing an explicit
{output_name} on each component.
No-Tree-Checks: true
Change-Id: I501c3f6c530e6d3896e2303ee75a0c4a4d07dfca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194732
Reviewed-by: Lutz Vahl <vahl@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85483}
Rolling v8/build: 3ed59a9..1015724
Rolling v8/buildtools: 0cc02fb..3c7e3f1
Rolling v8/buildtools/third_party/libc++/trunk: 1dfd002..1127c78
Rolling v8/buildtools/third_party/libunwind/trunk: bb5988e..e95b94b
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/45986b0..6cfc140
Rolling v8/third_party/depot_tools: 00be3f0..44e9bee
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230124.2.1..version:11.20230125.2.1
Rolling v8/tools/clang: 41fd15a..566877f
Rolling v8/tools/luci-go: git_revision:81e5cdad29bb4c7aaad98c843637513db3155b0d..git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7
Rolling v8/tools/luci-go: git_revision:81e5cdad29bb4c7aaad98c843637513db3155b0d..git_revision:221383f749a2c5b8587449d3d2e4982857daa9e7
Change-Id: If5bd9268220db8d5f49b57cd641a21c2bf2fe398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4196414
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@{#85480}
This reverts commit 20a954f4bc.
Reason for revert: Alas, GC stress failures:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/45646/overview
Original change's description:
> [heap][test] Fix weakrefs tests for conservative stack scanning
>
> 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.
>
> 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
>
> Bug: v8:13257
> Bug: v8:13662
> Change-Id: I53586bd16cdb98fa976e1fa798ef498bdf286238
> 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: Icc7a907928ccac058f8acdf320c21b2df04c1b78
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4192256
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85479}
This CL allows GetPredecessorIndex gracefully fail when an indirect
predecessor of the current block is passed as an argument.
Bug: chromium:1408354
Change-Id: I5eaab6c6905839e5833faea5c4b0540e4a63699b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191773
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85478}
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.
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
Bug: v8:13257
Bug: v8:13662
Change-Id: I53586bd16cdb98fa976e1fa798ef498bdf286238
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}
Avoid inlining if the function has exception handlers and/or
depends on incoming new target.
Bug: v8:7700
Change-Id: I25a19c6da94f333d0d57bcdb33392ee497c59e63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194199
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85476}
InitialValue points to the value in the stack relative to the frame.
In other words, the context and the closure of the inlined
function were incorrectly pointed to the parent one.
Bug: v8:7700
Change-Id: I740112168865b2eadadbb7eb0bdd63eba3e45bbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194198
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85475}
The invariants in this method are fairly strict since it is called
during object evacution and thus a) objects may be in transitory states
and b) multiple threads are working on evacuation objects concurrently.
Previously, this method ensured valid object accesses because only the
object currently being observed by ProfilingMigrationObserver was
accessed. This changed with crrev.com/c/4178821, where we (incorrectly)
also accessed another object (InstructionStream::code), leading to data
races and incorrect behavior.
This CL fixes that problem by changing LogEventListener API as follows:
void CodeMoveEvent(InstructionStream from, InstructionStream to);
void BytecodeMoveEvent(BytecodeArray from, BytecodeArray to);
With this change we again correctly observe invariants, and also remove
one use of AbstractCode.
Bug: v8:13654
Change-Id: Ida022e8c7f14d821e1139f025edc71c20fa386c0
Fixed: chromium:1409786
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194192
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85474}
This updates the file exceptions for js-fuzzer following the procedure
described at js_fuzzer/README.md.
This executed gen_exceptions.sh with the latest web_tests.zip archive.
FYI, the exceptions mark files with parse/mutation errors - i.e. the
fuzzer bails out and is ineffective on those files. It also marks
files not applicable in strict mode, which lets the fuzzer only
choose sloppy instead of bailing out. Some medium slow tests are
going to be chosen with lower probability.
This also fixes a bug in template literal replacements which reduces
the number of skipped test cases.
Change-Id: I39ae9b4c4f8dcff65226d49545eb50b1cbfe5c8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4184213
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85471}
Initial support for polymorphic loads using a single Maglev IR.
Bug: v8:7700
Change-Id: Ia1c800b60628636c6a9a0c153ab818fbc9d7540a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4178828
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85470}
After instruction stream refactoring, we were not printing the
assembler instructions anymore.
Change-Id: I450da42c9a79219b7f1c2230fae2ff65034e7449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191783
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85469}
The built-in wasm function behaves similar to
string.new_utf8_array but in case of invalid characters
returns `null` instead of throwing an exception.
There has been a similar change for string.new_utf8_try
at https://crrev.com/c/4177105 / 5628a2be90.
Bug: v8:12868
Change-Id: I4bcc5ed3b1b22beafd4910d317f363eb3762165e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191781
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85468}
CodeCreateEvent expects one of a) bytecode, b) builtins, c) baseline
code.
The invalid DCHECK was introduced in crrev.com/c/4178821.
Bug: v8:13654
Fixed: chromium:1409785
Change-Id: Ib12ca6e6ec722dcaaf02f3dc57a4bf24e2830a91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194188
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85467}
The wasm instruction string.compare performs a three-way
comparison and returns -1, 0 or 1 if the compared strings are
lessThan, equal or greaterThan.
It traps if either of the input values is null.
Bug: v8:12868
Change-Id: I4082f22d38e46447eb841c71955521297128237d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191772
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85466}
In the concurrent marker during visitor dispatch a FixedDoubleArray
might be left-trimmed right between loading the visitor_id and the
downcast of the HeapObject to FixedDoubleArray with FixedDoubleArray::cast. This forces us to use the unchecked_cast
method like we already do for FixedArray or some string types.
Bug: chromium:1409000
Change-Id: Ia8c1f68fd19e07529d5820e121f142c1ed16b21a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191776
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85465}
Rolling v8/build: d2dda6b..3ed59a9
Rolling v8/buildtools: 37cb03b..0cc02fb
Rolling v8/buildtools/third_party/libc++/trunk: 885d5d1..1dfd002
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7bfa128..45986b0
Rolling v8/third_party/depot_tools: b88a434..00be3f0
Rolling v8/third_party/fuchsia-sdk/sdk: version:11.20230122.2.1..version:11.20230124.2.1
Change-Id: I3a980206a31a50d6c2dff98a4a91fe85de3ae031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4193349
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@{#85464}
