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}
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}
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 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}
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}
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 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}
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}
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}
--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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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 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 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}
