With the recent introduction of unicode sets (v-flag), nested character
classes are allowed in regular expressions.
We always expect a nested class to be of type
`RegExpClassSetExpression`, but the empty nested class was not handled
correctly.
Bug: v8:11935, chromium:1412942
Change-Id: I3b644c8627d8fc6b320a419216372810e8003983
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4224311
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85680}
Shared Large Object Space was added with the introduction of shared
space, but it was never swept.
Besides leaking memory, this led to issues as mark bits were never
cleared and object bodies not re-visited. If the map of an object changed, we would miss visiting potentially newly introduced pointer fields (e.g. SeqString -> ExternalString), freeing EPT entries that were still in use.
Bug: v8:13267, chromium:1407167
Change-Id: Id7bea2ebfbc5a4d935af4b97b7474d64d609a95d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221578
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85669}
These tests are unsuitable for "stress concurrent allocation" mode,
because it triggers GCs that interfere with the execution of
FinalizationRegistry cleanup tasks or with the clearing of WeakRefs.
Bug: v8:13257
Bug: v8:13713
Change-Id: Id43d95b53d3f68f1f70ad6ee9ff8e08e70007d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221575
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85668}
Markbits on read only pages are initialized BLACK and never change. For
any practical purposes they are unused.
This CL prevents any access to the markbits of these pages. This is a
precursor to removing them entirely from the page to make room for
static roots.
Bug: v8:13466
Change-Id: I61d3f6d9bbca750d0f34475859b34ff44f7fec1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212397
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85665}
This is a reland of commit 0d4200055b
gn complained about headers that are only included behind the
v8_use_perfetto build flag. Added "nogncheck" to suppress this
warning.
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: Ifdcc9983230b5e7bab5f66a37f193d2cee698400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221573
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85650}
This reverts commit 2e357c4814.
Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux%20MSAN%20no%20origins/33231/overview
Original change's description:
> [wasm-gc] Introduce wasm null object
>
> We introduce a wasm null object, separate from JS null. Its purpose is
> to support trapping null accesses for wasm objects.
> This will be achieved by allocating a large payload for it (larger than
> any wasm struct) and memory-protecting it (see linked CL). The two null
> objects get mapped to each other at the wasm-JS boundary.
> Since externref objects live on the JS side of the boundary,
> null-related instructions in wasm now need an additional type argument
> to handle the correct null object.
>
> Bug: v8:7748
> Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85648}
Bug: v8:7748
Change-Id: Ie53febf49b946217e0057959c757d811a97ca1eb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219105
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85649}
We introduce a wasm null object, separate from JS null. Its purpose is
to support trapping null accesses for wasm objects.
This will be achieved by allocating a large payload for it (larger than
any wasm struct) and memory-protecting it (see linked CL). The two null
objects get mapped to each other at the wasm-JS boundary.
Since externref objects live on the JS side of the boundary,
null-related instructions in wasm now need an additional type argument
to handle the correct null object.
Bug: v8:7748
Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85648}
When folding constants in the MachineOperatorReducer, we should be
careful that arithmetic instructions producing int64 outputs aren't
replaced with booleans represented as int32.
Fixed: chromium:1407384
Change-Id: Ib536a53084b12bbb205308c642ee32c0f2e1e418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219023
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85646}
Some patterns that were valid with /u are invalid with /v.
This CL adds a UseCounter for such usages in /u to get an idea how often
they are used in the wild.
This is important information w.r.t the proposal to use /v instead of /u
for the pattern attribute (http://go/gh/whatwg/html/pull/7908).
Chromium CL: https://crrev.com/c/4221395
Bug: v8:11935
Change-Id: Idc023ceba9ce03eee578d6c387ce8a8f37db292f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212393
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85639}
The {CallWasmFunctionForTesting} function currently receives arguments
as a pair of {int} and {Handle<Object>*}. Encapsulating this as a
{base::Vector} makes the relation more clear and improves readability at
call sites.
R=ahaas@chromium.org
Change-Id: I884f8d0dc1c33389b60cc53750f2e3bfcaf644a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218353
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85638}
We sometimes get non-reproducible exception mismatches in the fuzzers.
This might come from OOM exceptions.
This CL makes us print some information about them, so we learn more
from the occasional fuzzer reports. In a follow-up we can then handle
OOM exceptions better, if that turns out to cause this.
R=ahaas@chromium.org
Bug: chromium:1412084
Change-Id: Ic0bf3880fe733320c2532c0f69d8f88fe9c9ff5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217417
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85624}
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}
