Rather than requiring the user of a LocalIsolate to pass in a
RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the
scope in the LocalIsolate directly and use its RuntimeCallStats in the
LocalIsolate constructor.
We can't do this for the main thread LocalIsolate, since
WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so
there we use the main-thread RuntimeCallStats instead.
This flushes out some issues of background-thread LocalIsolates being
used on the main thread, so fix those too, as well as RCS scopes using
background counters for operations that could happen on the main thread.
Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78334}
Design doc: bit.ly/36MfD6Y
We introduce simplified operators LoadImmutableFromObject and
InitializeImmutableInObject. These are lowered to Loads and Stores like
LoadFromObject and StoreToObject.
We split CsaLoadElimination::AbstractState in two HalfStates,
which represent the mutable and immutable component of the state.
Immutable operators in the effect chain modify the immutable half-state,
and plain operators modify the mutable half-state. The immutable part is
maintained through write effects and loop headers. Immutable
initializations do not lookup and kill previous overlapping stores,
assuming each offset cannot be initialized more than once.
Bug: v8:11510
Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78325}
This reverts commit 91f08378bc.
Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
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}
Previously, since the source code for the synthetic class instance
member initializer function was recorded as the span from the first
initializer to the last initializer, there was no way to reparse the
class and recompile the initializer function. It was working for
most use cases because the code for the initializer function was
generated eagarly and it was usually alive as long as the class was
alive, so the initializer wouldn't normally be lazily parsed. This
didn't work, however, when the class was snapshotted with
v8::SnapshotCreator::FunctionCodeHandling::kClear,
becuase then we needed to recompile the initializer when the class
was instantiated. This patch implements the reparsing so that
these classes can work with FunctionCodeHandling::kClear.
This patch refactors ParserBase::ParseClassLiteral() so that we can
reuse it for both parsing the class body normally and reparsing it
to collect initializers. When reparsing the synthetic initializer
function, we rewind the scanner to the beginning of the class, and
parse the class body to collect the initializers. During the
reparsing, field initializers are parsed with the full parser while
methods of the class are pre-parsed.
A few notable changes:
- Extended the source range of the initializer function to cover the
entire class so that we can rewind the scanner to parse the class
body to collect initializers (previously, it starts from the first
field initializer and ends at the last initializer). This resulted
some expectation changes in the debugger tests, though the
initializers remain debuggable.
- A temporary ClassScope is created during reparsing. After the class
is reparsed, we use the information from the ScopeInfo to update
the allocated indices of the variables in the ClassScope.
Bug: v8:10704
Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78299}
Treat all stack pointers as roots:
- Maintain a global linked-list of StackMemories
- Update StackFrameIterator to process inactive stacks
- Visit roots in all inactive stacks (including root marking and root
pointer updating).
Drive-by:
- Fix some issues uncovered by the test
- Refactor the builtin constants
R=mlippautz@chromium.org,ahaas@chromium.org
Bug: v8:12191
Change-Id: I5b6381f9818166e2eabf80dd59135673dddb2afc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310932
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78291}
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
which stores a couple of pointers and most importantly the Zone and
AstValueFactory of the parse. This allows the Zone and AstValueFactory
to be reused across multiple parses, rather than re-initialising
per-Parse.
With this, we can amend the LazyCompileDispatcher to initialise one
LocalIsolate, Zone and AstValueFactory per background thread loop,
rather than one per compile task, which allows us to reduce per-task
costs and re-use the AstValueFactory's string table and previous String
internalizations.
Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78289}
On the way to a cheaper and more scalable stack frame representation
for the inspector (crbug/1258599), this removes the need to expose
both what was called "function name" and what was called "function
debug name" on a v8::StackFrame instance.
The reason to having a distinction between that the V8 API exposes
and what the inspector exposes as frame function name is that after
the initial refactoring around v8::internal::StackFrameInfo, some
wasm cctests would still dig into the implementation details and
insist on seeing the "function name" rather than the "function
debug name". This CL now addresses that detail in the wasm cctests
and going forward unifies the function names used by the inspector
and the V8 API (which is not only needed for internal consistency
and reduced storage requirements in the future, but also because
Blink for example uses v8 API and v8_inspector API interchangeably
and assumes that they agree, even though at this point Blink
luckily wasn't paying attention to the function name):
- The so-called "detailed stack trace", which is produced for the
inspector and exposed by the v8 API, always yields the "function
debug name" (which for example in case of wasm will be a WAT
compatible name),
- while the so-called "simple stack trace", which is what is used
to implement the CallSite API and underlies Error.stack continues
to stick to the "function name" which in case of wasm is not
WAT compatible).
Bug: chromium:1258599
Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78283}
This is a reland of 2d087f237e
The changes are :
* Fix redundant reinterpret_cast in test file for MSVC failure
https://crbug.com/v8/12476
* Fix flaky test
https://crbug.com/v8/12475
If a sample is captured during a GC, no embedder context is obtained
defaulting to EMPTY. This is the expected behavior, made it in clear
in implementation and in test.
* Synchronized the embedder context filter behavior with existing
native context filter.
Original change's description:
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871
Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78281}
This reverts commit 863bc2b88a.
Reason for revert: https://crbug.com/1276923
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: chromium:1276923
Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78277}
Checks whether a Persistent is used from the creation thread on slow
path allocations. In practice, these currently happen every 256
Persistent allocations. This is a best effort check that may help to
flush out issues that are missed with DCHECK builds.
Bug: chromium:1276570
Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78276}
This CL adds the following specific cases, to make sure they are
correctly handled by the slow path:
- the backing store of a TypedArray gets detached after optimisation
- passing null instead of a TA doesn't lead to a deopt
Bug: v8:11739, chromium:1052746
Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78274}
This removes the additional call to `didPause` solely for
instrumentation breakpoints. They will be reported along with any
other pause reasons, and if several apply, 'ambiguous' will be
reported as a reason.
Bug: chromium:1229541
Change-Id: I38557248dc2274c2ff2c396aa19073f4a5c5abd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300134
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78271}
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}
This aligns the Torque semantics of catch with the JavaScript behavior:
When we catch an exception, we also reset the pending exception.
This also fixes a long-standing bug that we didn't restore the original
pending message after executing arbitrary JS in IteratorCloseOnException
Bug: v8:12439
Change-Id: I268d9d639d09023a424f352547cdce03428f983a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303805
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78259}
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}
This reverts commit 2d087f237e.
Reason for revert:
- Causing MSVC build failures: https://crbug.com/v8/12476
- Causing flaky failures: https://crbug.com/v8/12475
Original change's description:
> [profiler] Surface VM & Embedder State
>
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871, v8:12475, v8:12476
Change-Id: I02670b1ed3bb863033208369227642a7419fce00
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315444
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78256}
Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
EmbedderState:
* An EmbedderState is defined as a value uint8_t and a v8::context used
for filtering.
* EmbedderStates are stack allocated by the embedder, construction and
destruction set/unset the state to the isolate thread local top.
* A v8::context is used to filter states that are added to a CpuProfile,
if the CpuProfile do not have a ContextFilter set or if contexts do not
match, state defaults to Empty.
* v8:StateTag is already propagated all the way to a Sample, simply add
an API to surface it.
VMState:
Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
Bug: chromium:1263871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78250}
This CL makes sure that the API reports an error if the embedder
attempts to create a fast API function which could be used as a
constructor. It also adds corresponding cctest.
Bug: chromium:1052746
Change-Id: I36e51b298889900131bd5c3894134df3d8d28e5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314856
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78243}
When performing a shared GC, we need to find references from the client
heaps into the shared heaps. For now we achieve this by simply
iterating all objects in client heaps.
We need to do this both for marking and when updating pointers after
evacuation.
Bug: v8:11708
Change-Id: Ic1dd94cc352be0404095e548979c37b1ef25682a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300142
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78240}
This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.
The new interface is not yet stable and may change at any time without
deprecating the old version first.
Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
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/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
This is in preparation for supporting concurrent access in
String::SlowEquals, which will need to compare character buffers with
relaxed ordering.
Bug: v8:12007
Change-Id: Ie8ac62c15df48ebd605985c35b843b510c7ad167
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313467
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78231}
Previously, StoreStoreElimination handled allocations as
"can observe anything". This is pretty conservative and prohibits
elimination of repeated double stores to the same field.
With this CL allocations are changed to "observes initializing or
transitioning stores".
This way it is guaranteed that initializing stores to a freshly created
object or stores that are part of a map transition are not eliminated
before allocations (that can trigger GC), but allows elimination of
non-initializing, non-transitioning, unobservable stores in the
presence of allocations.
Bug: v8:12200
Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78230}
Rather than creating a ParseInfo when creating a BackgroundCompileTask
(and passing ownership across to the BG thread which deallocates it),
create one when running it.
This allows the ParseInfo Zone to be both allocated and deallocated on
the same thread, which will improve its allocator friendliness.
As a side-effect, we now use the on-heap PreparseData from the
SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
means that we don't have to copy the PreparseData across Zones, but we
do need to Unpark the LocalHeap when accessing preparse data.
Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78228}
If multiple isolates are running concurrently and one of them calls
`quit`, we should not delete the counters map, because another isolate
might still access it.
R=mlippautz@chromium.orgCC=nikolaos@chromium.org
Bug: v8:12453
Change-Id: I6d41478f188f0043b7d6055b0872574c28fd3039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310807
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78226}
This allows streamed sources to also trigger parallel compile tasks. The
chunk vectors are shared via std::shared_ptr.
Clone chunked streams are initialised with a null source, and are not
allowed to fetch any more data. Similarly, the original stream is not
allowed to fetch data if it has been cloned (since the vector is shared
and would mutate if we added more data to it).
This is ok for the purposes of cloning for parallel compile tasks, as we
fully parse before cloning for the task.
Change-Id: Ic268e4956e0894acb63111bf0aaf32eaad426066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310917
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78209}
This CL makes sure to forward the information that we are pausing
because of a debugger statement, and to encode it explicitly
as an 'other' reason when reporting the pause to the front-end.
Drive-by: refactoring the way break reasons are propagated by
introducing a new enum for break reasons
Bug: chromium:1229541, chromium:1133307
Change-Id: I9d2e8d8da54d96a231eff9d1f62b74507955b18f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306978
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78202}
We optimize away type upcasts for nominal types in WasmFullDecoder.
Upcasts trivially hold for nominal types, which is not the case for
structural types. Note that we already optimize away trivially-failing
checks (when types are unrelated) for both nominal and structural types.
Bug: v8:7748
Change-Id: I720c9803cb8b4071aa4bae112ce06d587b7a68fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306984
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78201}
This fixes data races when lazily creating counters (and populating the
{counter_map_}, and when concurrently adding samples to the counters.
It also ensures that the Wasm engine is stopped (via {V8::Dispose})
before printing and deleting counters, as background threads might still
try to update the counters otherwise.
R=mlippautz@chromium.org
CC=nikolaos@chromium.org
Bug: v8:12453, chromium:1275117
Change-Id: Ie6beea6cc74eea52143d12f9921597da4a250f2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78191}
When emitting code, character ranges must only specify ranges which
the actual subject string (one- or two-byte) may contain.
This was not always the case, specifically for ranges with
`from <= kMaxUint8` and `to > kMaxUint8`.
The reason this is so tricky: 1. not all parts of the pipeline know
whether we are compiling for one- or two-byte subjects; 2. for
case-insensitive regexps, an out-of-bounds CharacterRange may have an
in-bounds case equivalent (e.g. /[Ÿ]/i also matches 'ÿ' == \u{ff}),
which only gets added somewhere in the middle of the pipeline.
Our current solution is to clamp immediately before code emission. We
also keep the existing handling/dchecks of the 0x10ffff marker value
which may occur in the two-byte subject case.
Bug: v8:11069
Change-Id: Ic7b34a13a900ea2aa3df032daac9236bf5682a42
Fixed: chromium:1275096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306569
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78186}
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}
c++17 is being enabled on some platforms:
https://crrev.com/c/3306812
which causes gcc to emit the following warning:
```
error: null argument where non-null required (argument 2)
memcpy(storage_ + kReturnCount, param_types.data(),
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Unlike clang, gcc is not able to detect if memcpy is actually
being executed or not when src is NULL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22179
Therefore need to disable this warning at this location.
Change-Id: I44da9f698ef724e39bb9c7d4b235d1004d52f491
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308916
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78182}
Try blocks (whether catch or finally) will unconditionally create
handler tables and start a new basic block for the exception handler.
This can accidentally resurrect a dead block when the entire try block
is dead (and hence can never enter the exception handler in the first
place).
Add a deadness check to BuildTryCatch/Finally to fix this.
Bug: chromium:1273677
Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78179}
Until now, LABs were accessed from generated code via external
references, e.g., see NewSpaceAllocationTopAddress() and
NewSpaceAllocationLimitAddress().
This patch places them in the IsolateData, so they can be accessed
using Isolate-constant offsets. It affects the hot path of all TF
generated code.
Bug: v8:12428
Change-Id: I7bfd54bea4febead404829d8e0b058b6cf53a374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303800
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78176}
Currently, JSFinalizationRegistry has a BodyDescriptor that iterates
next_dirty as a custom weak field, and it has a WeakListVisitor that
cleans up any items from the list that should be removed. However, none
of that code is used, because JSFinalizationRegistry objects are created
with visitor ID kVisitJSObjectFast. This change gives them a custom
visitor ID so that next_dirty can be treated as weak.
Bug: v8:12430
Change-Id: I31c1935257ad508b13a3e684662d2ca406d8ed19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307096
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78167}
- V8::Deprecate ShutdownPlatform in favor of V8::DisposePlatform
- Rename i::V8::TearDown to i::V8::Dispose
- Clean up i::V8::Initialize
- Remove needless V8::Initialize() calls in cctests
- Remove CcTest::DisableAutomaticDispose()
- Add checks to Isolate::Allocate and Isolate::Dispose that there is
and active platform
Change-Id: Iac84f9ade9d1781e9e8b8c88ea8fe74013f51c4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306482
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78162}
This will allow making HeapObject::IsBlah() checks faster when external
code space is enabled.
Bug: v8:11880
Change-Id: I68473ba88063c555c90330c9748462adeb35aa0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308797
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78156}
The CL converts uses of v8::internal::Worklist to heap::base::Worklist
which does not require to know the number of tasks working with the
work list upfront. heap::base::Worklist is the common implementation
for V8's heap and cppgc and should be used/optimized going forward.
Bug: v8:12426
Change-Id: Id6ef1aa05df858b01df90d653b6421a9bb68b997
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306382
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78151}
Previously when hitting a debugger statement we would ignore reporting
the hit breakpoints.
Bug: chromium:1229541, chromium:1133307
Change-Id: I47427a541391a27fc7783930e5e7eb41fbf2bb6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306373
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78145}
--experimental-wasm-mv has been removed, and --wasm-loop-unrolling is on
by default.
Change-Id: I094870765031ef46fcec95e9071333e4e80f407b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302805
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78140}
{WasmInternalFunction::external} might return a function that is not
a WasmExportedFunction, at which point the code in ProcessTypeFeedback
fails.
See crrev.com/c/3277878 for context.
Bug: v8:12436, v8:12166
Change-Id: I09ef96df3fc051586044dd9c2ce88d6aeeb34b9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306391
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78139}
memory[1] needs to be set in LE order even on BE platforms.
Change-Id: I44620c30a25719d0d61e0f14490342ee930dbbb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302852
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78136}
With https://crrev.com/c/3272577 we introduced a `StackFrame` cache for
the inspector, which is keyed on the script ID, line and column number,
so the syntactic properties of the function. However, the name that we
report for functions is dynamic and can change (per closure) by
explicitly reconfiguring the "name" property via
```js
var f = function() { /* ... */ }
Object.defineProperty(f, "name", {value: "super duper function"});
```
for example, so we need to take that into account as well, and only use
the cached `StackFrame` instance if the dynamic names still match up.
Otherwise we just overwrite the cached entry with a new instance (the
assumption here is that "name" isn't reconfigured often).
Fixed: chromium:1274529
Bug: chromium:1268436
Change-Id: I519017c762aed5b4f93b9dc4553fa81d5979f1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306376
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78127}
To trigger speculative inlining, a function needs to run a few times on
Liftoff-tier, and then tier-up to Turbofan. We make sure this happens
by enabling --wasm-dynamic-tiering with a small budget, and running
the critical functions until {%IsLiftoffFunction} is false.
We also add an additional test.
Bug: v8:12166
Change-Id: I6c5e0d3f1e3ba0df8510ae6850d8e9af1d01c179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306372
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78123}
Previously, we would encode 'other' as a reason for pausing when
stepping too, however, it would not show as such in case it would
overlap with another reason. This CL makes sure that we always report
'other' as a reason if we are stepping.
Drive-by: only encode 'other' as a reason once
Bug: chromium:1229541
Change-Id: Id73822dff68d1d54a2f1fafdf2a097e1377ece75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295346
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78118}
This allows the embedder to determine whether some function has been
called from a destructor.
See discussion in
https://crrev.com/c/3302810
Bug: chromium:1273928
Change-Id: Icb5d98eff777574488a7d6de5e693c502c2fb53e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303793
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78113}
See crrev.com/c/3277878 for context.
We should only transform extenral to internal function references when
passing a function value to a function-typed global or table. For their
externref counterparts, we should preserve the reference unchanged.
Bug: v8:11510, chromium:1273705
Change-Id: Ic1719c4d31e175f3a37ced6e4e4dfcd61a19ae57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302790
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78108}
... and thus avoid the need for special handling of objects located
in external code space.
This will also allow making HeapObject::IsBlah() checks faster when
external code space is enabled.
Bug: v8:11880
Change-Id: I12d07c05451ff198f0a6182d9b5849f76015e7fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300140
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78104}
SIMD tests moved from the proposal directory to the main spec test
directory. Test expectations needed to be adjusted therefore.
Change-Id: I02225da1f55ba173bbda22257edf45a3e987ba0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302795
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78101}
In addition, make the code less confusing and more future proof:
- initialize the JSArrayBufferView bit_field to 0 (not only zeroing the
relevant bits)
- serialize it as uint32, since it's an uint32.
Bug: v8:11111
Change-Id: Iffbbb27cc8c821587f992668bfbcf2448a776f15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300132
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78075}
The newly-failing tests are due to the renaming of "anyfunc" to
"funcref".
R=ecmziegler@chromium.org
Change-Id: I801b330e386c45e62a1cbc6e308a981b3b0244e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300133
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78070}
The main changes of this CL are:
It should no longer be assumed that an empty ArrayBuffer has a nullptr
backing store. This is in preparation for the move to caged pointers,
which cannot represent nullptr, and will instead likely provide a
EmptyBackingStore constant pointing inside the virtual memory cage. For
that reason, a new JSArrayBuffer::IsEmpty() helper is introduced, which
should be used instead of checking against nullptr.
CodeStubAssembler::GetTypedArrayBuffer now checks for on-heap
TypedArrays instead of comparing the backing store pointer to nullptr.
This is consistent with the implementation in JSTypedArray::GetBuffer.
v8::ArrayBufferView::CopyContents now uses JSTypedArray::DataPtr instead
of relying on nullptr backing stores to handle on-heap TypedArrays.
The serializer and deserializer now check for IsEmpty() and use the
kEmptyBackingStoreRefSentinel value to serialize empty backing stores.
Empty ArrayBuffers allocated for on-heap TypedArrays now have a
byte_length of zero. This allows removing the allocation_length() (and
allocation_buffer()) methods, which were only (incorrectly, as they
don't account for GSABs) used for memory measurements.
Bug: chromium:1218005
Change-Id: Ib889ccf855f68525f7a614f3963e46ea56865fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297709
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78069}
Design doc: bit.ly/3jEVgzz
We separate the internal representation of function references in Wasm
from their JSFunction-based (external) representation. This improves
performance of call_ref by requiring less indirections to load the
context and call target from a function reference. In the boundary
between wasm and JS/the C API, we add transformations between the two
representations.
Detailed changes:
- Introduce WasmInternalFunction, containing fields required by
call_ref, as well as a reference to the corresponding
WasmExternalFunction. Add a reference to the WasmInternalFunction in
WasmFunctionData. The {WasmInternalFunction::FromExternal} helper
extracts the internal out of an external function.
- Change {WasmInstanceObject::external_functions()} to internal
functions.
- Change wasm function tables to contain internal functions.
- Change the following code to use internal functions:
- call_ref in liftoff and Turbofan
- function type checks in liftoff and Turbofan
- CallRefIC and GenericJSToWasmWrapper builtins
- {InitExprInterface::RefFunc}
- module-compiler.cc in {ProcessTypeFeedback}
- In module-instantiate.cc, in function-rtt creation.
- Add transformations between internal and external functions in:
- WasmWrapperGraphBuilder::{ToJS, BuildUnpackObjectWrapper, FromJS,
BuildJSToJSWrapper}.
- debug-wasm-objects.cc in {FunctionProxy::Get},
{WasmValueObject::New} and {AddWasmTableObjectInternalProperties}.
- runtime-wasm.cc in ReplaceWrapper
- the C and JS APIs
- module-instantiate.cc, in import and export processing, as well as
{InitializeIndirectFunctionTables}
- WasmTableObject::{IsValidElement, SetFunctionTableEntry}
- {WasmGlobalObject::SetFuncRef}
- Simplify body descriptors of WasmExternalFunction variants.
- Adjust tests.
Bug: v8:11510
Change-Id: I8377f46f55c3771391ae1c5c8201a83854ee7878
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277878
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78068}
In the final version, we might parse the parameters when deserializing
instead, but this approach is more suitable for prototyping.
Bug: v8:11525
Change-Id: I000869877b03fd1909acf602ab5190951b1939e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295456
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78065}
This is a reland of d7c3f1cd8a. It fixes
a build failure on native arm64.
Original change's description:
> Reland "[fastcall] Enable float support on arm64 simulator"
>
> This is a reland of b9ddcbc86f
>
> The original CL was reverted due to an MSAN issue, that is fixed by
> moving the signature mapping onto the Isolate (instead of having
> per-thread storage, which got invalid on multithreaded compilation).
>
> This CL also contains fixes for the Bazel config and for a data race
> when obtaining the PerIsolateSimulatorData.
>
> Original change's description:
> > [fastcall] Enable float support on arm64 simulator
> >
> > This CL adds support for handling calls to C functions with arbitrary
> > signatures on the arm64 simulator. It adds infrastructure for
> > encoding the signature data from CallDescriptor and FunctionInfo
> > classes into a compact representation, stored in the simulator and
> > called EncodedCSignature.
> >
> > Design doc:
> > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
> >
> > This CL is a follow up on the native support added in
> > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> > and is partially based on the previous attempt:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
> >
> > Bug: chromium:1052746
> > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> > Commit-Queue: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77744}
>
> Bug: chromium:1052746, chromium:1267854
> Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78018}
Bug: chromium:1052746, chromium:1267854
Change-Id: Ib495573569a6c930b8f9e5f1fe7ff46eb57a0aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295461
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78063}
1. The default locale may be reset / is not immutable as we thought.
2. A suffix of ignorable code points after the common length affects
the comparison result.
Bug: v8:12196
Fixed: v8:12398
Change-Id: I6f60f56352956779df801c43de6ebac8cd9c592d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291314
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78053}
Private methods use a property with symbol name that stores a context.
This is then loaded to perform the brand check. Since this uses
JSLoadProperty in Turbofan, we should not type JSLoadProperty as
NonInternal.
Bug: chromium:1269063, v8:12359
Change-Id: I920ccf46e939ab0477ff2fdb3cda6d7d94bab0af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293089
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78042}
Bug: v8:12228
Change-Id: I21b2ee1e640ba75227a03d765bb1552eff68e3fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293415
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#78033}
It is possible to inline a JSToWasm wrapper that directly calls a
WasmToJS wrapper. In this case we need to make sure that the instance
we pass is a WasmApiFunctionRef, not a WasmInstanceObject.
Bug: chromium:1271456
Change-Id: I684a769922895860a43c73ba43c2598c9bda4b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293423
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78031}
No implementation needed, since relaxed swizzle is already handled in
wasm-compiler, and is visited by VisitI8x16Swizzle, and on arm64 we
generate the same code (TBL).
Bug: v8:12284
Change-Id: I446632101de26bb2f28c3f3ed60f209e81600dec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272643
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78026}
This reverts commit d7c3f1cd8a.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Android%20Arm64%20-%20debug%20builder/22043/overview
Original change's description:
> Reland "[fastcall] Enable float support on arm64 simulator"
>
> This is a reland of b9ddcbc86f
>
> The original CL was reverted due to an MSAN issue, that is fixed by
> moving the signature mapping onto the Isolate (instead of having
> per-thread storage, which got invalid on multithreaded compilation).
>
> This CL also contains fixes for the Bazel config and for a data race
> when obtaining the PerIsolateSimulatorData.
>
> Original change's description:
> > [fastcall] Enable float support on arm64 simulator
> >
> > This CL adds support for handling calls to C functions with arbitrary
> > signatures on the arm64 simulator. It adds infrastructure for
> > encoding the signature data from CallDescriptor and FunctionInfo
> > classes into a compact representation, stored in the simulator and
> > called EncodedCSignature.
> >
> > Design doc:
> > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
> >
> > This CL is a follow up on the native support added in
> > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> > and is partially based on the previous attempt:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
> >
> > Bug: chromium:1052746
> > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> > Commit-Queue: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77744}
>
> Bug: chromium:1052746, chromium:1267854
> Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78018}
Bug: chromium:1052746, chromium:1267854
Change-Id: Ia8f10d085d13990b331f306957f95ecf3e003cfd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295453
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@{#78019}
This is a reland of b9ddcbc86f
The original CL was reverted due to an MSAN issue, that is fixed by
moving the signature mapping onto the Isolate (instead of having
per-thread storage, which got invalid on multithreaded compilation).
This CL also contains fixes for the Bazel config and for a data race
when obtaining the PerIsolateSimulatorData.
Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}
Bug: chromium:1052746, chromium:1267854
Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78018}
There are cases where DeclareEvalVar can fail to create a variable, in
particular when the declaration scope is not extensible. Throw an error
in such cases.
Fixed: chromium:1145119
Change-Id: I6260f570570c4d7801231bdb5f6724f3734444fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295348
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78017}
This is a reland of 90a9d6cb13
The original CL got reverted because of two different issues:
* The DCHECK failure on AllowGarbageCollection::IsAllowed() got fixed
in https://crrev.com/c/3289625.
* The crash with the incremental marking job were because of a nested
GC started from a SafepointScope. This CL adds IgnoreLocalGCRequests
scopes to SafepointScopes in src/heap.
In addition this CL prevents shared GCs during isolate deserialization
by locking the clients_mutex_ until the isolate is fully deserialized.
The original GC used a DisallowSafepoints scope to prevent shared GCs
from interrupting isolate deserialization.
Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}
Bug: v8:11708, v8:12375, v8:12377
Change-Id: I9d1af6fbc06a3a8b6f216ec5e9027665ad071809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283067
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78013}
This is a partial revert of https://crrev.com/c/2033171 to bring back
WasmModuleObject::Compile, that compiles Wasm bytes into a Wasm module.
Also adding a simple test to make sure the compile works.
There are some users, e.g. Cloudflare, Halide, see bug for more details.
Bug: v8:10461
Change-Id: I199abea108311025decad793d2232a08bba05d38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3292088
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78003}
`foo ## __LINE__` just emits foo__LINE__ because of how preprocessor
expansion works.
The typical solution for this is to use a CONCAT macro, but we in fact
already have a helper for what this is trying to solve,
UNIQUE_IDENTIFIER, so just use that instead.
Change-Id: Icea3f01db458c5d557e0affd3b004f4478c6c315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293084
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77998}
The cpu profiler tests require a precise trace and become
flaky when running with concurrent sparkplug.
Bug: v8:12054
Change-Id: I62a20d15530c610bc1091371781c28687c718720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289158
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77972}
This CL explicitly encodes the 'other' reason for breaking for:
* regular breakpoints
* triggered pause events.
The reason for explicitly encoding the reason is that we may otherwise
not know why we pause when we handle it. This knowledge is needed
in order to fully support instrumentation breakpoints, e.g. if we do
not know that we paused on a triggered pause, and this happens to
overlap with an instrumentation, we would previously only report
'instrumentation' as a reason which would be wrong.
Bug: chromium:1229541
Change-Id: I93c08f965a491f6d34f280157b182a78d5b3cf07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289638
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77970}
Prior to this CL we regularly generated high counts of code
dependencies, and installation was not the most efficient.
This CL 1) implements early dependency deduplication and
2) simplifies the way dependencies are persisted on the heap
through DependentCode.
Re 1): we dedupe twice, once based on the CompilationDependency
contents, and again once we know the final target object.
Re 2): Instead of a linked list of weak fixed arrays per
dependency group, store deps in a flat array together with a
bitset of their dependency groups.
See also:
https://docs.google.com/document/d/1B34S1s3Iv6hbquZ93RugD0b-ZKfHEptJ8Fk_YyOvjDk/edit
Bug: v8:12195,v8:12397
Change-Id: I9ab47f6d87b10558194b5de30a36b1122f7e362a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283074
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77969}
We prevent unrolling of loops with indirect calls. We expand the set of
permitted wasm builtins in unrolled loops.
Bug: v8:11298
Change-Id: I70b8ff3b16d9b0d3a4ea2d103f8ffb74083fd2a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289152
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77965}
We have 4 different cases:
1) Explicit web snapshots (--web-snapshot) & errors in the snapshot
2) Explicit web snapshots & errors in the embedded script
3) Auto-detected web snapshots (--experimental-web-snapshots) & errors
in the snapshot
4) Auto-detected web snapshots & errors in the embedded script
Before this CL: cases 2 & 4 resulted in a DCHECK failing and the error
in case 3 wasn't reported correctly.
This CL implements consistent error reporting for all of them.
Bug: v8:11525
Change-Id: If2e5039d9769b9cad2175dfd5c4f91edf61111ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277877
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77963}
Extend BitsetType of TF's type system from 32 to 64 bit.
At the moment all 32 bits are used, so we can't add any new types.
This CL only adds support for > 32 types to C++. The bitset is also
mirrored in Torque. In the Torque definition, we just expose an
unstructured uint32 for the higher bits of the bitfield, because Toruqe
can't deal with 64 bit types on 32 bit platforms (yet) and we also can't
have multiple 1-bit bitfields within a single class (yet).
Bug: v8:12392, chromium:1262750
Change-Id: If571491443e86e4e47eb88d3f15eca485344d12d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281922
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77962}
We move the mask to be the first input of the node in wasm-compiler.cc,
this matches the order for S128Select, which makes code-gen for
arm/arm64 simpler (directly lower to BSL with no more shuffle of
inputs). This requires tweaking of input indices in the instruction
selector for ia32/x64, but no change in codegen.
Bug: v8:12284
Change-Id: I1f6f1a9fe0869509be77f77b6f54a0c636a0f92d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272640
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77958}
Bug: v8:12228
Change-Id: I9f7bb60fb2647f44c41c8c9e35a534ecd60c426a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289150
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#77957}
NONE clashes with the PropertyAttributes::NONE, which is defined in
v8::internal namespace. PropertyAttributes have too many call sites
and depend on using the enums as masks, making it hard to convert
to an enum class. So we are changing the name instead.
Bug: v8:12244
Change-Id: Iec0be12c626549cca137aceeaee0e30fafab8b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284003
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77956}
CodePageCollectionMemoryModificationScope was wrongly added to the test.
On M1, the code object is unprotected to RW and crash when running it later.
Bug: v8:12386, v8:12396
Change-Id: I1af3dabaa9b66d1f50033f298107949fcb35c3d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289155
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77947}
This fast path works for ASCII-only strings and is similar to the
existing fast-path in C++. Important differences:
- The locale check is done at Turbofan optimization time instead of
at runtime
- Use tables of size 256 instead of 128 to save a bounds-check when
handling one-byte strings.
- It first performs an equality check that's optimized for detecting
inequality quickly by comparing the strings from both ends. If the
equality check succeeds, we are done. Otherwise chances are high
that the strings differ according to collation level L1 already.
Therefore, we first do an L1 check and perform the L3 check
only when L1 didn't find a difference. This is based on the assumption
that few strings are identical except for different capitalization.
- Use the Torque version of string flattening instead of the runtime
version.
Bug: v8:12196
Change-Id: I2d043c1138846783f6d567b736d34063ba9301e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268465
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77946}
Use recursion scope only for nullable references in the
GenerateRef function. We declare the recursion scope as
an optional and only initialize it if the reference type
is nullable.
Bug: v8:11954, chromium:1270126
Change-Id: I1548290cc9d48167f6fd56ff653744d472f65635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284894
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Cr-Commit-Position: refs/heads/main@{#77943}
On 32-bit architectures, we need to run Int64Lowering on the inlinee
code to make it compatible with the caller code.
Since Int64Lowering now runs while a GraphReducer is active, only one of
them can use node marks to store node states. Therefore, we move the
Int64Lowering node states to an internal map.
Bug: v8:12166
Change-Id: I53b85442d503e71fa533e06568f4b9db572a4401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283072
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77941}
Move the source code position for classes to the point where the block
context has already been created. Previously, there would be a mismatch
between the context and the scope when using the ScopeIterator.
We paused at a point where, according to the source position, we already
are in a class scope, but according to the bytecode (context), we would
not yet have created the block context for the class.
Also-by: leszeks@chromium.org, jarin@chromium.org
Fixed: chromium:1259878
Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77940}
Declare more macro lists to split up W0 and W1, then disassemble using
the macro lists.
Change-Id: I4a73c24ea63c5a7b7489b81ee5ec7026c1765091
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270598
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77934}
Implement f32x4.qfma, f32x4.qfms, f64x2.qfma, f64x2.qfms.
These were already implement in macro-assembler-x64, so move the
implementation to shared-macro-assembler.
x64 has a macro list in fma-instr, copy this to ia32, and then use this
macro list to define existing vfma{ss,sd} instructions in
assembler-ia32.
Disassembly support is intentionally omitted in this patch, I will add
this in a follow-up. The currently disassembly in x64 is quite verbose
and I would like to make use of macro-list but it requires breaking up
the macro list into smaller parts, so I will do that refactoring for
both ia32 and x64 in the follow-up.
Bug: v8:12284
Change-Id: I3654ea108a123467506c5837072b6b63ecbc74da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3255664
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77932}
This CL refactors how the first byte(s) of the input are used to set
internal configuration, like which compiler to use and whether Liftoff
will be used as reference instead of the interpreter.
We now always use exactly one byte, and use it for all internal
configuration. If more bits are needed in the future we can either
extend to two bytes, or use the same bits for multiple things, while
avoiding to lose coverage of all interesting configurations.
For now, we use the first byte to derive
- which compiler to use per function,
- whether to use Liftoff as reference, and
- (new) whether to globally enable the mid-tier register allocator.
R=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I2cae6628554ca8f7e08115015b36f9f0a6b8c34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253156
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77929}
Otherwise, DCHECKs complain that the PageAllocator used for the
GlobalGCInfoTable may differ when setting up the platform repeatedly
through benchmarking SetUp().
Change-Id: I7e87e8c9d8c283105e1bd75a4cd176df7f304315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283075
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77920}
Also introduce USE_ALLOCATION_ALIGNMENT_BOOL constant which is true
only for those configurations that require aligned allocations and
use it for statically falling back to unaligned allocations on those
configurations that do not require aligned allocations.
This is a prerequisite for introducing the real kWordAligned mode for
kSystemPointerSize aligned allocations.
Bug: v8:8875
Change-Id: I155d12435f344324bc1bf19da88ee823c8f2ca6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283064
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77918}
Due to a bug on AIX, some of the glibc FP functions do not
preserve the sign bit when a negative input is passed by
value and the output is rounded to 0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97086
This CL continue the fixes previously added here:
https://crrev.com/c/2468618
Change-Id: I2afa1f67ac1d29ec0606de6d6ebcf05be0664b8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3282308
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77915}
The stored value might be an allocation that can be removed once the
Store node is removed. We need to revisit this node manually because
inputs in a node removed with ReplaceWithValue are not revisited
automatically.
Bug: v8:11510
Change-Id: I57cb8955a3e2f7143474ad7ced9d946e6d1cc18e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277880
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77899}
Posting compile tasks from the parser has several issues:
1. We don't know how many functions there will be total, so we can't
yet allocate shared_function_infos array on the Script
2. Without this array, inner function compiles can't look up their own
inner functions during bytecode finalization, so we can't run that
finalization before script parse completes
3. Scope analysis can't have run yet, so we can only post top-level
function tasks and if we allocate SharedFunctionInfos early they
are forced into a bit of a limbo state without an outer ScopeInfo.
Instead, we can post compile tasks during bytecode generation. Then, the
script parse is guaranteed to have completed, so we'll have a
shared_function_infos array and we will have allocated ScopeInfos
already. This also opens the door for posting tasks for compiling more
inner functions than just top-level, as well as generating better code
for functions/methods that reference same-script top-level
let/const/class.
Bug: chromium:1267680
Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77894}
Complete implementation of Heap::MakeHeapIterable() by also making the
LABs of paged spaces iterable. This method is the one to use when
the heap and/or a particular space shall be iterable.
Bug: v8:12338
Change-Id: Id859cf1a05df21a54939c504c59d7b1ccd659c9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277888
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77891}
In each wasm CallDescriptor, we store the signature of the call based on
the real parameters passed to the call. This signature is more precise
than the formal function signature. We use this signature in inlining
to enable more optimizations.
Changes:
- Add wasm_sig_ field to CallDescriptor.
- Construct the real signature in {DoCall} and {DoReturnCall} in
graph-builder-interface, and pass it to all call-related functions in
WasmGraphBuilder.
- Update {ReplaceTypeInCallDescriptorWith} to use ValueType over
MachineType. Construct the updated function signature.
- In wasm-inlining, kill the Call node after inlining.
- Add two tests.
Bug: v8:11510
Change-Id: Ica711b6b4d83945ecb7201be26577eab7db3c060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270539
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77889}
FLAG_wasm_dynamic_tiering is still off by default. When enabled,
it now uses the technique previously behind --new-wasm-dynamic-tiering.
Bug: v8:12281
Change-Id: I365c2c066e62418cd6abc7830f95d1fe0f950e33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275570
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77883}
Under certain conditions GC could flush bytecode array from
SharedFunctionInfos. This CL ensures that the bytecode array is always
available for reconstructing source positions.
Bug: chromium:1265570
Change-Id: I2ce7eb04201f69121687ab0aaa2af42adb2caae0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275569
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77877}
UnprotectAndRegisterMemoryChunk should only be called if we have
CodePageCollectionMemoryModificationScope or
CodeSpaceMemoryModificationScope open.
This also fixes cctests that create code objects without a
code modification scope.
Bug: v8:12054
Change-Id: Id931f1f8120050b2bb76ef3d5701b9a32e52ff37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277882
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77873}
Unify parse post-processing between main-thread and background-thread
parsing, now that we have LocalIsolate and can Internalize on background
threads.
As part of this, simplify the LocalIsolate parking pattern to explicitly
park during ParseOnBackground, rather than being implicitly parked when
ParseOnBackground is called. This reduces the amound of scoping needed
in the BackgroundCompileTask::Run method.
Change-Id: Ifdb128b763129bda78bd1bae89dac1c62f872350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277876
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77872}
Due to streaming, the SFI enqueueing can happen concurrently with with
main-thread finalising, so we need to add locks around accesses to the
SFI->Job map.
Bug: v8:12370
Change-Id: I60281a954ef10f7fcde559b9529077a6b9a82c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277874
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77869}
This fixes a -Wshadow warning for NO_FLAG. The other option is to
make it an enum class, which makes test-conversions.cc a bit verbose.
Bug: v8:12244,v8:12245
Change-Id: I3ea429eb45e31b25d4c6658ceb86c33ba280ae51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3274015
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77860}
Similar to previous bug v8:11771, this test needs deterministic GC
behavior so it is incompatible with concurrent inlining.
Bug: v8:12374, v8:4578
Change-Id: Ib3667744d1032524a0c2e697a970876dfc1677ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272882
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77851}
Loop headers in the interpreter would start a new basic block, which
among other things would reset the liveness of that block. This meant
that a loop created after dead code, without a check for whether the
code is currently dead or not, would "resurrect" that block's liveness,
making the inside of the loop live even though the loop itself is
unreachable.
This works fine, since the loop is still unreachable, but can breaks
DCHECKs in bytecode liveness analysis for cases where a register is
supposed to be initialised before the loop, in the dead code, and is
then used inside the loop, in the resurrected code.
Normally this wouldn't be a problem, since blocks are normally killed on
the statement level and we check for deadness during statement
iteration, but `foo() = x` introduces an expression-level block killer
(being re-written to `foo[throw ReferenceError] = x`) and we don't check
for deadness after assignment Lhs preparation.
This does mean that we have to fix the InterpreterJumps test, to not try
to jump into the middle of a loop (since this could revive the loop).
This can only happen when manually creating bytecode, bytecode generated
from JavaScript is always reducible.
Bug: chromium:1230597
Change-Id: I8403ccdeae7e5450adf629026e2ca8a134c81877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275557
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77846}
This reverts commit 90a9d6cb13.
Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.
Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
Changes:
- Enable allocation folding for wasm-gc graphs.
- Improve structure of wasm escape analysis code. Kill dead nodes.
- Revisit object node after eliminating a load or a store to that node.
- Add a couple of tests, rename one test file.
Bug: v8:11510
Change-Id: I8b3c5186cd0a8827744a05eba366ff79bc7bc975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264215
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77840}
The second parameter of Int64Mul may be a 64-bit immediate value,
treating it as a 32-bit value will lose the upper 32 bits.
Besides, add a test for this error.
Bug: v8:12373
Change-Id: I92e95f7906051c91f9076730e5490b0956416d68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272195
Auto-Submit: Liu yu <liuyu@loongson.cn>
Commit-Queue: Liu yu <liuyu@loongson.cn>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77833}
The is_shared bit bumps the number of reserved bits for Strings'
InstanceType from 6 to 7. This has the side effect of shuffling the
InstanceType enum values.
There are no users of this bit yet. This is steps 1-2 from the following
design doc [1], in preparation for sharing internalized and
in-place-internalizable strings.
[1] https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edit?usp=sharing
Bug: v8:12007
Change-Id: Idf11a6035305f0375b4f824ffd32a64f6b5b043b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266017
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77831}
Rename flags to align them with other flags that are named in an
enabled way and drop the "never" prefix.
Drive-by: Refactor compaction entry point.
Bug: v8:12251
Change-Id: If2b189152f3cd22038b87fe3cc2ba0db4953ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270534
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77813}
Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.
The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.
This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.
This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.
Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}
This flag is now enabled by default for quite some time in production.
In addition that flag was already defined readonly and couldn't be
disabled, so let's remove this flag for good.
Bug: v8:10064
Change-Id: I0e71eee9d25960a96324d56c8f0191fe678dc6e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268907
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77806}
The GC already treats some embedded object pointers in Code as weak,
based on Code::IsWeakObject. If one of those embedded objects ends up
unmarked during a full mark-collect GC, then the Code is marked for lazy
deoptimization and the embedded objects are cleared. However, many of
those same objects are often held strongly by the deoptimization literal
array for the Code, which causes memory leaks. This change updates the
deoptimization literals array to store those objects weakly. Any Code
currently executing on the stack might need those deoptimization
literals in order to deoptimize, so the deoptimization literal array is
marked strongly in that case.
Design document:
https://docs.google.com/document/d/1gFRBYCeqz9Mysx8CVYQkldBbk3AZLo8UX0DMLZV_7qw/edit?usp=sharing
Bug: v8:4578
Change-Id: I02e86683c59371e9f88ecf523750c9c6afebdb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160299
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77805}
In assignments the lhs should be evaluated first and shouldn't be
re-evaluated when the value of the rhs is available. Fix it by
saving the receiver and the key registers into AssignmentLhsData
before building the assignment and use them later, instead of visiting
the AST again to retrieve the receiver.
In addition, now that we save the receiver register, use it to
perform the brand check even when we know for sure that it's
going to fail later because it's a write to a private
method or accessing the accessor in the wrong way (v8:11364),
so that the brand check error always appears first if it is present,
as specified in
https://tc39.es/proposal-private-methods/#sec-privatefieldget
Drive-by: unify the brand check error messages, and replace "Object"
with "Receiver" in the messages for clarity. The instance private
brand check now throws "Receiver must be an instance of class <name>"
and the static private brand check now throws "Receiver must be
class <name>". Also always set the expression position to the
property load position, because the brand check failure comes from
the load operation.
Bug: v8:12352, v8:11364
Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77797}
In the future we will allow arbitrary objects as host-defined options.
To prepare the embedders for the upcoming changes we migrate the API
to use v8::Data where possible.
Internally we still use i::FixedArray with primitive values until the
migration to context-stored host-defined options is completed.
Note: This CL also introduces a temporary cast and inheritance
between Data and PrimitiveArray which will be removed again.
Bug: chromium:1244145
Change-Id: I852d0d827708d32b6f3a6d03457234a006e2fd77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264285
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77795}
In order to construct the optimal source code combination for functions
(and especially the positions inside the optimal source code for each
function), we need to know all functions upfront.
Rewrite the d8-based snapshotter so that it discovers all objects first
(+ assigns ids), then does the actual snapshotting.
Bug: v8:11525
Change-Id: I4f4e5589575ee9738e8a83aa6cda2c8164803b4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268915
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77794}
Adds support for aborting compaction when finalizing with stack:
- never_compact_with_stack: All pages are aborted;
- never_compact_code_space_with_stack: Only code space pages are
aborted;
This flags allow simulating a worst case where a stack cannot
be considered precise, or evacuation candiate is refered to from
a stack slot that V8 has no info for.
Bug: v8:12251
Change-Id: Ice24ac87a985b8ecf7b5cbb5c106ad4a3ae1944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173682
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77792}
This CL fixes a memory leak where we would not properly pop all
Promises from the Isolate-wide Promise stack. This can happen under
the following conditions:
- `await`ing a Promise in an async function
- Debugger is active
- AsyncEventDelegate is not set.
In the case above, the promise of the surrounding async function is
pushed onto the global Promise stack, but not poped before the
await. This CL fixes that.
R=bmeurer@chromium.org
Fixed: chromium:1225905
Change-Id: If03f6bfda48b8cb14bc6a68815fd702632edc68d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268464
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77790}
This reverts commit b9ddcbc86f.
Reason for revert: Hits unreachable on MSAN, see https://bugs.chromium.org/p/chromium/issues/detail?id=1267854
Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}
Bug: chromium:1052746, chromium:1267854, chromium:1267841
Change-Id: If3d5aaab6b5f4309ce90add614d674aaa86b43c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268910
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77788}
Relaxed f32x4 and f64x2 min and max.
These instructions only guarantee results when the inputs are non nans,
and when the inputs are not 0s of opposite signs.
Drive-by rename of instruction codes to be Minps/Maxps/Minpd/Maxpd
since they map down exactly to a single instruction.
ia32 port of c3f346b7ac.
Bug: v8:12284
Change-Id: If64da551524ea8c304e1fa8f9cf4acbd54abfe5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251708
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77780}
4 instructions, i8x16, i16x8, i32x4, i64x2 relaxed lane select. These
instructions only guarantee results when the entire lane is set or
unset, so vpblendvb will give correct results for all of them.
Same instruction selector code as x64.
Bug: v8:12284
Change-Id: Icd0bc8c5125cd2780141117830d6cb6e6babbb74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251701
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77779}
Explicit write barriers for internal fields are deprecated as they are
automatically emitted by V8.
Depends on:
https://crrev.com/c/3263924
Bug: v8:12356
Change-Id: I171ba5b42a6570ce52e2e2ea1b7c1029d5a8a3a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263888
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77772}
This CL
* adds forwarding accessors to CodeDataContainer for certain widely
used Code object's fields and predicates,
* adds JSFunction::set_code() overloads accepting CodeT values,
* migrates SharedFunctionInfo getters to CodeT,
* migrates InterpreterData::interpreter_trampoline to CodeT.
Drive-by-fix: replace #if V8_EXTERNAL_CODE_SPACE with #ifdef to be
consistent.
Bug: v8:11880
Change-Id: I1e114076a0568068038ca6f70a86431a3a9cfb9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262716
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77762}
This CL fixes a null dereference when an attempt is made to access
the current arm64 simulator from a background thread.
Bug: chromium:1267491
Change-Id: I9232fe134fccbff162eb5076aff20884872e4cc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264219
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77757}
Since the indirect function table at index 0 in an instance is now
represented like the other tables, the IndirectFunctionTableEntry
abstraction is no more useful. We replace it with direct access to the
tables and a simpler abstraction {FunctionTargetAndRef}.
Bug: v8:11510
Change-Id: Iab4a6ca7eda8eb1757dbd321cb3997e98e78267e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247030
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77754}
Internal fields are used for implementing edges to C++ objects in
Oilpan. When setting the fields on a JS API object, we should also
emit a write barrier for this edge.
This mechanism replaces the explicit write barrier in V8's API which
is provided through `JSHeapConsistency::*`.
The internal barrier should also be slightly faster as it doesn't
require any API calls.
Bug: v8:12356
Change-Id: I639d18141acfb910d0ded8d987d8a0916e25431d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257709
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77749}
After the snapshot data ends, interpret the rest as normal JS code.
Bug: v8:11525
Change-Id: I8de4cf4027e582e6b8e330dda7708623373d2675
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263896
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77741}