The function relied on passed pointers always being compressed, which
is no longer the case with subtle::UncompressedMember<>.
Bug: chromium:1412021, chromium:1412221
Change-Id: I531e41d24fcab34e527db99f8047123f254e8a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217411
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85623}
There is no real difference between MacroAssembler and TurboAssembler
anymore. Initially the idea was to differentiate thread-safe
operations, but it got out of hand. With LocalHeaps we could ensure
differently by passing a local_isolate.
In this CL:
TurboAssemblerBase was renamed to MacroAssemblerBase
The file containing it also renamed from turbo-assembler to macro-assembler-base.
TurboAssembler and MacroAssembler were merged into MacroAssembler
in each of the architectures.
turbo-assembler-unittests-arch were included in
macro-assembler-unittests-arch
tasm renamed to masm
Bug: v8:13707
Change-Id: I716bbfc51b33ac890c72e8541e01af0af41b6770
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212396
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85610}
This was never supported to start with and can cause invalid script names.
This CL partially reverts https://crrev.com/c/3513892
Drive-by-fix: Dehandlify more code.
Change-Id: I96cf4c1244d9f00dc47738cd481b440e6bed0541
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4174074
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85609}
This reverts commit 0d4200055b.
Reason for revert: Breaks integration bots, and blocks API changes : https://ci.chromium.org/ui/p/v8/builders/try/v8_linux_chromium_gn_rel/83678/overview
Original change's description:
> Reduce build size when building with Perfetto SDK
>
> Building Chromium with full Perfetto SDK included increases build time
> significantly. We can reduce this overhead by including only those
> parts that are required. See b/266913150 for context.
>
> Change-Id: I0cde5cb7df7b6151ec686e993488d8467c416fac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212390
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
> Cr-Commit-Position: refs/heads/main@{#85603}
Change-Id: I88210ada35e0d7e68a0dbccad518cf6177303430
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4216171
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85606}
Building Chromium with full Perfetto SDK included increases build time
significantly. We can reduce this overhead by including only those
parts that are required. See b/266913150 for context.
Change-Id: I0cde5cb7df7b6151ec686e993488d8467c416fac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212390
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#85603}
This is a follow-up to https://crrev.com/c/4204032 which allowed
wrapper inlining for the nullable externref type.
Bug: v8:7748
Change-Id: I5a82c37b7cf0cfcbcacbe399f8b3119176c3bba4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212394
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85598}
Drive-by refactoring: Make it evident that currently we upload additional files only for Android platform.
Bug: v8:13686
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel
Change-Id: I8081c1185d6a92dfdcef82e697e301f3e7838dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205916
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#85592}
In JavaSCript implementations that supports ECMA-402,
`Array.prototype.toLocaleString()` must invoke the `toLocaleString` method of
each non-undefined, non-null elements witch exactly two (2) arguments.
See: https://tc39.es/ecma402/#sup-array.prototype.toLocaleString step 6.c.i.
V8 appears to provide no arguments when locale is undefined and to not provide options when options is undefined.
Bug: v8:13564
Change-Id: I655917210554d20d2eaebe2ac333421dd5d157ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4184564
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Auto-Submit: Juan José <soyjuanarbol@gmail.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85588}
This means TurboFan might not see what Maglev did, and it might make
different decisions, but if we deopt we'll learn in Ignition anyway and
won't make the same mistake later. At the same time this avoids a lot of
unnecessary operations that impact tight loops.
Bug: v8:7700
Change-Id: I6fada2ed0218b0b97fc8c9d9ba10fb2218cd71d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200631
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85585}
- Remove camel-case Code accessors like InstructionStream since
they only make sense on Code (where we have to distinguish between
embedded builtins and other Code).
- Remove the prefix from 'raw_'-prefixed accessors since it was
intended to clearly disambiguate from the camel-case accessors and
is now no longer needed.
- Remove various dead functions.
- Update comments.
Bug: v8:13654
Change-Id: Ife51e4aef502fc30ab1526c205a49e5620be96f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205925
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85580}
Port commit 76a817e03a
Also, rename the enum variable in FFlagsMask from kOverflow to kFPUOverflow to avoid redefinition due to the commit 949bd4467d.
Change-Id: I83e42d4cb0cf48d678719572adb008ef101b23e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4204830
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji.odyssey@gmail.com>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#85577}
Per the WebIDL specification, objects that are namespaces must have the
their class string value set to their identifier name [1]. Since per
spec, console is defined as a namespace [2], console's class string must
be "console".
However, since the console object in Chromium/v8 is directly implemented
inside of v8, it doesn't adhere to the WebIDL binding norms. Its
implementation manually had its @@toStringTag set to "Object", which is
incorrect. This CL corrects it to "console" and adjusts test
expectations accordingly.
Unfortunately, this CL will have web-exposed changes to Chromium that
are not tested anywhere, specifically because console's implementation
of namespace did not adhere to the WebIDL spec. Separately,
https://crrev.com/c/4193348 fixes Chromium's web-exposed tests and
stable test expectations, to manually treat console as a namespace
(despite its broken implementation) so that the global interface listing
tests properly enumerate attributes/methods on the console object.
Once this CL lands, those expectations will need to be changed.
The motivation for this change is to ensure that all console attributes
and methods are properly accounted for in the usual Blink webexposed
stable tests that are owned by the Blink API OWNERs. This is because
recently, v8 shipped a new console method (createTask()) that entirely
bypassed the Chromium launch process:
https://www.chromium.org/blink/launching-features/, because no files
needed to be approved by Blink API OWNERs.
[1]: https://webidl.spec.whatwg.org/#ref-for-dfn-class-string%E2%91%A8
[2]: https://console.spec.whatwg.org/#console-namespace
Change-Id: I0bbd05242fc815945cce40c65d74995950d64115
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4193308
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85572}
Shared objects have fixed layout (i.e. immutable maps) and start off
sealed. Ordinary JS objects allow writable properties to be redefined to
be non-writable. This violates the fixed layout invariant and needs to
be disallowed.
Also contains a drive-by fix removing
@highestInstanceTypeWithinParentClassRange, which is unneeded.
Bug: chromium:1407595, v8:12547
Change-Id: I0257fa19f59ccfaaf0e07cb42aeedd71e132d21a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4190525
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85570}
.. 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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
This adds the APIs for the embedder to
1) request compile hints collection for a script
2) retrieve the compile hint data
Bug: chromium:1406506
Change-Id: Ic23430d3cff9fe71faa71f4c7be6635467e14268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4154427
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85461}
We currently skip a few memory64 spec tests; some for missing rebase,
some for unknown reasons.
It turns out that all of the failures are due to missing rebase on bulk
memory or reference types.
This CL documents that in the comment and removes a TODO.
R=jkummerow@chromium.orgCC=sbc@chromium.org
Bug: v8:13692
Change-Id: I0ddf2bee0dcc36af5bc39251ed7b6b83d8de9aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191771
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85457}
