This is a reland #3. The fixes were landed separately.
Perf Sheriffs: this CL might regress some benchmarks while improving
the others.
Bug: v8:11880
Change-Id: I8ed5bf59360649718960dc34c06015ee6ff1532a
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_compile_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422643
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78854}
We can now specify the trials for clusterfuzz using the file
clusterfuzz_trials_config.json. There is also a presubmit check
to make sure that it is formatted correctly.
Change-Id: Iafb7063b63b1daeb7653830542d13b419cf187d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416191
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78848}
This reverts commit 517ed4ad00.
Reason for revert: There still seems to be an issue on V8 Win msvc related to this CL (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/20568/overview).
Original change's description:
> Reland "[Torque] Generalize Torque literals to larger size"
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Changes in the reland: Simplified IntegerLiteral to single digit.
>
> Bug: v8:7793, chromium:1289282
> Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78811}
Bug: v8:7793, chromium:1289282
Change-Id: I818cec9625fbd827a4a30088d8c8b759fb6c50d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3424484
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78847}
Drive-by fix to align what builds the test runner considers to be able
to have shared memory features and what builds can create a shared
Isolate.
Bug: v8:12007
Change-Id: I151513ccbfbee31e5b35c5ce8e9192732eabfee2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3421507
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78824}
- It changes ContextSlotIndex from static to non-static.
- Updates ContextSlotIndex and ScriptContextTable::Lookup to use
handles, since it is necessary for the NameToIndexHashTable::Add
- Adds a NameToIndexHashTableLookup to CSA.
- Renames LocalNamesIterator to LocalNamesRange and iterates the
hashtable when local names are not inlined.
Bug: v8:12315
Change-Id: I2c8c933002fe73f4def145bc207825823262d743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406751
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78818}
This is a reland #2. The fixes were landed separately.
Perf Sheriffs: this CL might regress some benchmarks while improving
the others.
Bug: v8:11880
Change-Id: I397aef5ad5cce42ef189ee10b482805c90ec925a
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_compile_dbg
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417000
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78817}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Changes in the reland: Simplified IntegerLiteral to single digit.
Bug: v8:7793, chromium:1289282
Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78811}
Create and return the chained promise, which resumes the suspended wasm
continuation once the JS promise resolves:
- Add stub for the WasmResume builtin, which will resume the given
suspender.
- Add the JS function wrapper for the builtin.
- On suspension, return promise.then(onFulfilled) to the prompt.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I2d6136b2bd610daa4be1880f347b7bdf897e75ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404776
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78787}
This reverts commit 757830b02b.
Reason for revert: Speculatively revert due to a number of
performance regressions
Original change's description:
> [Torque] Generalize Torque literals to larger size
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Bug: v8:7793
> Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78671}
Bug: v8:7793
Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78706}
Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Bug: v8:7793
Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78671}
In preparation to use the hash table in the scope_info, we
setup a hashtable from name to indices.
Bug: v8:12315
Change-Id: I77f1eb40191c2fb2d40127e1e84dbc41ca2e4b70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386804
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78646}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
- Add suspend asm builtin stub, and call it from the suspending
wasm-to-js wrapper
- Rename frame type to match both builtins (prompt and suspend)
- Add suspend bool to the import cache key
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: Ie5a8ca7cbe4bcb91697e05b6470e3d632d608993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345004
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78628}
kScopeInfoMaxInlinedLocalNamesSize is a threshold for inlined storage,
otherwise local names will be stored in a hash table.
Bug: v8:12315
Change-Id: Ibfa5bec5222c9e60765c3663707623544895ec0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386601
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78622}
This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
The original CL introduced a test that does not work when it is executed
concurrently on multiple isolates. This CL skips this test
configuration.
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
Change-Id: I36ce90b37736172aa01c47ab04e154ec8ea2d8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380590
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78564}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@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@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
Without the comma, the two strings '--no-enable-sse3' and
'--noenable-ssse3' will be concatenated, resulting in missing detection
for the no_simd_hardware flag.
R=liviurau@chromium.org
Bug: v8:12521
Change-Id: Icbdc5e8057d1eeead472f76efd52c379bffbe5b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372914
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78528}
If such a frame is near the top of the stack frame, move to the frame
below instead, which is the caller of OS::DebugBreak.
Also, rename dcheck_stop_handler to v8_stop_handler since we handle more
than DCHECKs there.
R=leszeks@chromium.org
No-Try: true
Change-Id: Ib31c2dc8278ec779a00babfdc952453e66e5f110
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366238
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78481}
Commit 84f3877c15 moved IsInRange to
base::IsInRange and updated src/parsing/keywords-gen.h, but did not
update tools/gen-keywords-gen-h.py.
Bug: v8:12507
Change-Id: I914ba73feac3bac6fd5d08d14d17149faf6c5c76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3356200
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78467}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
This is the final change list in the list of refactorings to split off
the implementations of v8::StackFrame and CallSite objects (as used by
the V8 JavaScript stack API). See https://bit.ly/v8-stack-frame for the
whole story.
This CL adds the v8::internal::StackFrameInfo class as new backing
implementation of v8::StackFrame, and puts it into debug-objects.tq
to indicate that it's used for the debugger API only. This new class
is lightweight and only holds on to static information about the
stack frame, and is thus usable for the V8 inspector to implement
async stack traces in a cheaper manner going forward.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278650
Fixed: chromium:1278647
Change-Id: I4dbf2d850f47797263af225895129499169aad02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302794
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78382}
This is the second step in the refactoring to make v8::StackFrame
more lightweight and usable for (long time storage) by the V8
inspector (see https://bit.ly/v8-stack-frame for an overview).
This is a purely mechanical change without any functional aspects.
The intention is to make the use case for the CallSiteInfo objects
clear, namely to serve as the backing store for the CallSite objects
exposed via the Error.prepareStackTrace() API and used under the
hood to implement the error.stack accessor.
Doc: https://bit.ly/v8-stack-frame
Bug: chromium:1258599, chromium:1278647, chromium:1278650
Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78361}
During a shared GC we need to iterate the twice: for marking and later
when updating pointers after evacuation. This CL introduces a new
remembered set to avoid the second heap iteration, the remembered set
is created when iterating the client heaps for marking. When updating
pointers, the GC only needs to visit slots in the remembered set.
CLIENT_TO_SHARED is only used during GC atm.
Bug: v8:11708
Change-Id: Ie7482babb53b5f6ca2115daafe6f208acae98d6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315443
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78332}
Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
the sets and hashmaps, and instead:
1. Turning the pending job set into a queue, and
2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
the LazyCompilerDispatcher::Job, instead of maintaining an
IdentityMap from one to the other.
To avoid bloating all UncompiledData, this adds two new UncompiledData
subclasses, making it four subclasses total, for with/without Preparse
data and with/without a Job pointer. "should_parallel_compile"
FunctionLiterals get allocated an UncompiledData with a job pointer by
default, otherwise enqueueing a SFI without a job pointer triggers a
reallocation of the UncompiledData to add a job pointer.
Since there is no longer a set of all Jobs (aside from one for
debug-only), we need to be careful to manually clear the Job pointer
from the UncompiledData whenever we finish a Job (whether successfully
or by aborting) and we have to make sure that we implicitly can reach
all Jobs via the pending/finalizable lists, or the set of currently
running jobs.
Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78302}
This is a reland of 3ee4804f83.
The CL was originally reverted for blink test failures. Since the
revert, the blink top-level await flag has been removed.
Original change's description:
> [top-level-await] Remove --harmony-top-level-await
>
> TLA has been shipped since v8.9.
>
> Bug: v8:9344, chromium:1271114
> Change-Id: Ibebf21da8bacb1f0d212390133847495ad8553e5
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/3307103
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78169}
Bug: v8:9344, chromium:1271114
Change-Id: I96a9641967a23a12ba2467a69e5859ad8647f3e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318717
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78261}
For shared strings, String::MakeThin is protected by using the map word
of the string being migrated as a spinlock.
Note that this CL does not make it safe yet to access character data
from multiple threads. The spinlock here only protects write-write races
in String::MakeThin.
For more information, see the following two design docs:
https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edithttps://docs.google.com/document/d/1Drzigf17t4ofy0evDmaIL5p0MDZuAl95c9fSeX-QjVg/edit
Bug: v8:12007
Change-Id: I9c47412c6ec7360a672b65a8576b4f6156ee5846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313429
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78257}
--wasm-speculative-inlining makes no sense if --liftoff-only or
--no-liftoff, since it needs type feedback from Liftoff and is appied
by Turbofan. Therefore, it should be disabled in these cases.
Specifically, --wasm-speculative-inlining implies
--wasm-dynamic-tiering, which contradicts --liftoff-only.
Bug: v8:12166
Change-Id: Idc5e0d7ceb7dbdf82ea6fd14ffc8386fe35a1257
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306554
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78200}
This flag is not supported now.
Bug: chromium:1271841
Change-Id: I6a80ebed79a03164f58f1757b8ebaca74a681441
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306786
Auto-Submit: Junji Watanabe <jwata@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78198}
This CL removes the CallRefData data structure and accesses a funcref's
target and instance through the funcref.
Bug: v8:7748
Change-Id: Ic46b127f7775052d5df13b03c447e3b15328ad74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306486
Commit-Queue: Richard Stotz <rstz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78194}
Add suppose for compiling non-eager, non-top-level inner functions in
parallel, using the compiler dispatcher. This behaviour can be enabled
with --parallel-compile-tasks-for-lazy.
There are a couple of consequences:
* To support this we need support for off-thread ScopeInfo
deserialization, so this adds that too.
* The previous --parallel-compile-tasks flag is renamed to the more
descriptive --parallel-compile-tasks-for-eager-toplevel.
* Both parallel-compile-tasks flags are moved onto
UnoptimizedCompileFlags so that they can be enabled/disabled on a
per-compile basis (e.g. enabled for streaming, disabled for
re-parsing).
* asm.js compilations can now happen without an active Context (in
the compiler dispatcher's idle finalization) so we can't get a
ContextId for metric reporting; we'd need to somehow fix this if we
wanted asm.js UKM but for now it's probably fine.
* Took the opportunity to clean up some of the "can preparse" logic in
the parser.
Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78183}
