It's been enabled everywhere since Chrome 88, and the related
Chromium flag was removed in https://crrev.com/c/2886421.
Bug: v8:6532
Change-Id: I987a5761f9453d4e7d77d16199e8f0b3a659c70a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956131
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83809}
With a unique microtask queue possibly per context we need to pass
the microtask queue for the MicrotasksScope otherwise the default one
for the isolate will be used.
BUG=chromium:961186
Change-Id: Ib085f08e20185c69760aeea335d673d9c4c72999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3950216
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83803}
For MinorMC it is sufficient to finalize new space sweeping.
Starting MinorMC will only ensure that background tasks are paused and
all new space pages are swept.
Accounting becomes more complicated since we can have minor sweeping
and full sweeping running at the same time. To support that, new space
sweeping is split to a separate sweeping scope. Also, the
Notify*SweepingCompleted methods are updated for the possibility of
nested sweeping. The distinction is that Notify*SweepingCompleted
knows what kind of sweeping we want to finalize, but not what kind
is currently running.
Bug: v8:12612
Change-Id: If46fa3bc036080d4231171e613fa3aefe7400246
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945098
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83800}
Lowering the Clamp annotation relies on float rounding, which is
only supported with SSE4 enabled. Thus disabling generating the
fast call path if such arguments are present and SSE4 is disabled.
Bug: chromium:1374745
Change-Id: I14438902946d4744521dac8d8d314af51a722da5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3960410
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83799}
This is a reland of commit 2a7f86edcb
Original change's description:
> Reland "[v8] Use |AllocateAtLeast| for resizing v8 zones."
>
> This is a reland of commit 4444874cdf
> This fixes a failure on the UBSan bots caused by assuming |Realloc| is always in-place if the new size is <= the value of |malloc_usable_size|.
>
> Original change's description:
> > [v8] Use |AllocateAtLeast| for resizing v8 zones.
> >
> > This is part of an ongoing effort to reduce fragmentation in Chrome. Partition alloc shows v8 zones are a large user of memory in Renderer processes, and that there is fragmentation from these allocations. This CL will reduce this fragmentation by allowing v8 to use all allocated memory for its zones.
> >
> > Bug: v8:13193, chromium:1238858
> > Change-Id: Ibeac8bdba9d0e7ff66b14a3dde10e7c87d3cf953
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3889361
> > Reviewed-by: Adam Klein <adamk@chromium.org>
> > Commit-Queue: Thiabaud Engelbrecht <thiabaud@google.com>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#83235}
>
> Bug: v8:13193, chromium:1238858
> Change-Id: I923bcbce8403dd7d84642340fd7202087b8a4440
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3910268
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Thiabaud Engelbrecht <thiabaud@google.com>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83372}
Bug: v8:13193, chromium:1238858
Change-Id: Ie541f6d9cfe410e4f9c37bb5b2a5c44b7a71718e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3963703
Commit-Queue: Thiabaud Engelbrecht <thiabaud@google.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83795}
This is a reland of commit 4804c4de31.
There are major changes since the previous attempt:
- The WasmLiftoffFrameSetup (formerly WasmGetFeedbackVector) builtin
now performs as much of the frame setup work as possible, to reduce
generated code size for each function.
- The WasmLazyCompile builtin/runtime function no longer allocates,
hence gets frame type INTERNAL, and is un-handlified.
Original change's description:
> [wasm] Allocate feedback vectors on demand
>
> We previously allocated feedback vectors when instantiating the module,
> or when lazily compiling a function. That's not sufficient when there
> are multiple instances of the same NativeModule, or when we eagerly
> tier-down all code for debugging. This patch changes the "get vector from
> instance" sequence at the beginning of every Liftoff function to "get
> or allocate vector"; factored into a builtin call to avoid generating
> more code for every function.
>
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939667
> Cr-Commit-Position: refs/heads/main@{#83610}
Bug: v8:12852
Change-Id: I58a6a02a55c3e29cae3cbdafad6cf81487faccbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942206
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83794}
When creating a character class in unicode, case-insensitive mode we use
icu::UnicodeSet::closeOver() to add all characters that case-insensitive
match the characters in the class.
According to the spec only simple case folding shall be performed for
case-insensitive unicode matching, but closeOver() adds all characters
that are equal w.r.t full case folding.
The current approach of just removing strings from the closeOver set is
not enough, as single code point characters still remain in the set if
they were equal only by performing full case folding.
E.g. the characters \u0390 and \u1FD3 both fold to the same string
"\u03B9\u0308\u0301" via full case folding, but they don't have a simple
case folding in common.
To prevent these wrong matches, we calculate the set of all characters
with close overs that are wrong according to the spec at build time and
remove them from the set before adding case-insensitive equivalent
characters.
Bug: v8:13377
Change-Id: I0252c79143f266911691331dd0e1e27044ea8cba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952095
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83791}
CWasmArgumentsPacker stores ref types as full pointers even when pointer
compression is enabled and should calculate its buffer size accordingly.
Bug: v8:13388
Change-Id: I6c1c6b5ecd879af5ca61cbc2a31edfc660fdb036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3962030
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83779}
Collect feedback for small BigInt division and modulo operation in
the interpreter and use feedback for BigInt subtraction,
multiplication, and division in turbofan except modulo operation
because it is not supported yet in turbofan.
Bug: v8:9407
Change-Id: I931cf9f70778c866599611474f1834417f023a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948787
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83768}
Remove the dedicated MinorMC sweeping flag and merge with the
general concurrent sweeping flag.
Bug: v8:12612
Change-Id: I278f274e293a7160839259df38b4a2951df31e91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3936272
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83767}
--use-map-space was already disabled by default. This CL removes
the possibility to enable map space again by removing that flag and
all its usages.
Bug: v8:12578
Change-Id: I8af18f39e9bf645316aa8718b49589eb4b852374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3959658
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83758}
This CL fixes a bug in the block list handling for debug-evaluate.
Specifically, we can't rely on the source position alone to find
scopes. We also need to take the scope type into account. This needs
to happen in two places:
- When we try to find the closure scope in the re-parse
result based on the function at the top of the stack.
- When we try to find matching `ScopeInfo` objects from
re-parsed scopes.
Note that the code alrady contains a fix for a similar issue in
the past where we found class scopes instead of member initializer
function scopes. Both share the exact same source position.
This CL generalizes that fix to check that the scope type matches
when looking for the closure scope.
R=jarin@chromium.org
Bug: chromium:1363561
Change-Id: I18d167f59c994ece85971273954d0e3c65c12b7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3959915
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83757}
This CL fixes the ScopeIterator when it's created for a stack frame
that represents the script scope. For example the following script:
```
function foo() { debugger; }
foo();
```
Then a ScopeIterator created for the second stack frame (`foo()`)
should not a create a blocklist. This is somewhat a special case,
since the closure_scope_/start_scope_ are the SCRIPT_SCOPE.
Note that the debug-evaluate code can't run into this scenario as
we would never iterate far enough to actually trigger block list
calculation. Nevertheless, since it's possible to create a
`ScopeIterator` that could run into this scenario, we guard
against it.
R=jarin@chromium.org
Bug: chromium:1363561
Change-Id: I0677c257d41c9af5ffc38d390f58997da20fd069
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3960568
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83754}
The test occasionally times out, and it's unclear why.
This CL adds an explicit timeout to the test (30 seconds), and prints
all seen profiles after that. This makes it easier to see which frame is
missing from the profiles.
As a drive-by refactoring, we now also use
{InspectorTest.runAsyncTestSuite} instead of the hand-written sequential
execution of the asynchronous test functions.
R=thibaudm@chromium.org
Bug: v8:13370
Change-Id: I67f53a819706c8e5971bf32dc925d90b21c96243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956976
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83748}
Currently it falls back to runtime for externalized strings.
Bug: v8:7700
Change-Id: I9bc09969915e437af5fcf563ba74a6edd9280779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956975
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83745}
TypeGuard nodes interpret their inputs to be of a given type, which
might not be reflected in the graph and hence may lead to a type
conflict being reported by the Simplified Lowering Verifier. This
CL adds an additional SLVerifierHint node to preserve this type
information for the verification step.
Bug: v8:12619, chromium:1370398
Change-Id: I5e4117d6b3ada053249bc000ba98d04021395ce1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948704
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83739}
The implementation of bytecode flushing assumes that there is a single
owning SharedFunctionInfo for each bytecode. However, sometimes there
can be two, because a couple of code paths copy content from one
SharedFunctionInfo to another (BackgroundCompileTask::FinalizeFunction
and BackgroundMergeTask::CompleteMergeInForeground). Usually this works
out okay in practice, because we only copy content from a
SharedFunctionInfo when we're about to abandon all references to it.
However, we shouldn't rely on this lucky timing, especially considering
a possible future where conservative stack scanning could retain the
copied-from SharedFunctionInfo for an arbitrarily long time due to
spurious stack references. This change updates the bytecode flushing
implementation to correctly handle the case of two SharedFunctionInfos
that point to the same BytecodeArray.
I don't know if this fixes the linked bug, but so far it's the only
semi-plausible explanation I've found.
Bug: chromium:1359773
Change-Id: Iaa2c6e4953afcb46df2ac4b17828271151d85e59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916272
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83728}
If Liftoff is disabled, inlining could try to inline an invalid function
body. Thus run validation explicitly if the function was not validated
before.
R=jkummerow@chromium.org
Bug: chromium:1374535, v8:13371
Change-Id: If9ce17bb90259e265dc94dbb2f9e4fb97c338f14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956977
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83727}
The new ref.cast (opcode 0xfb41) takes any reference and
expects a Heaptype immediate. the HeapType can be a
concrete or an abstract type.
Differently to the old ref.cast instruction, it traps on
null. A variant which doesn't trap on null (ref.cast null)
will be added in a future CL.
Bug: v8:7748
Change-Id: Id5764a7553a57c5cb838682c9ec331d15d7d25c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948663
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83724}
Serialize tiering information in the profile (which functions were
executed, which functions were tiered up). Use this information during
compilation (only synchronous compilation supported so far) to
immediately compile or tier up those functions.
R=jkummerow@chromium.org
Bug: v8:13209
Change-Id: I13d859ae57f60dbdb0dad3f1daf7aa0b920526d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898997
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83720}
This is a reland of commit e3096c31d6.
The one additional use of FLAG_turboshaft is also rewritten now.
Original change's description:
> [flags] Remove FLAG_* aliases
>
> This removes the deprecated FLAG_* aliases, and switches remaining uses
> to the new v8_flags syntax.
>
> R=jkummerow@chromium.org
>
> Bug: v8:12887
> Change-Id: Icde494a3819a9b1386c91e44f5d72a55666d9eae
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952350
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83686}
Bug: v8:12887
Change-Id: I978df89f51e11c9a101ff3c1e385b1eced697a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3953292
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83717}
This CL fixes the ScopeInfo::Equals DCHECK when we update "unchanged"
functions. We don't need to make sure the outer scope info matches
exactly. LiveEdit already makes sure that outer scope infos don't
change in a way that would be bad for "unchanged" functions. It's
fine if they only change subtly by e.g. moving a outer context variable from `let` to `const`.
Note that we don't touch existing closures on the heap, those
will still reference the old scope info.
R=jarin@chromium.org
Bug: chromium:1363561
Change-Id: I5117d345d1f70e08ea436ed89f2c6deaff3f0538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3953496
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83713}
This CL aligns minor sweeping with full sweeping such that no
sweeping happens in the atomic pause. If concurrent sweeping is
disabled, sweeping will be either on allocation or when we start
the next GC.
This CL doesn't yet enable concurrent sweeping for MinorMC.
Regressions on benchmarks with MinorMC enabled are expected.
Bug: v8:12612
Change-Id: I6df808b94783559122ee78306af932809860703d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3934769
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83712}
This is a reland of commit 3b883e787d
Fixed a test case that was merged in the meantime still using the old
kExprRefAsData which is now called kExprRefAsStruct.
Original change's description:
> Reland "[wasm-gc] Ref types: Convert dataref to structref"
>
> This is a reland of commit 20327d1599
>
> Changed in reland:
> - Added new flag wasm-gc-structref-as-dataref which defaults to true
> and preserves the existing behavior.
> - Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
> - The flag affects static subtyping information between structref and
> arrays and the corresponding cast, test and br_on instructions.
> - Even with the old behavior the name still changed to "structref".
>
> Original change's description:
> > [wasm-gc] Ref types: Convert dataref to structref
> >
> > This change changes the type hierarchy in a non-backwards compatible
> > way: dataref is replaced with structref meaning that arrayref is
> > no longer a subtype of it.
> >
> > Bug: v8:7748
> > Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#83515}
>
> Bug: v8:7748
> Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83697}
Bug: v8:7748
Change-Id: I54f7b141ffc5b7597420fa0c838412be825a260b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952936
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83706}
This reverts commit 3b883e787d.
Reason for revert: gc-optimizations test is broken due to in-flight collision with another CL: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8800403395649311857/+/u/Check/gc-optimizations
Original change's description:
> Reland "[wasm-gc] Ref types: Convert dataref to structref"
>
> This is a reland of commit 20327d1599
>
> Changed in reland:
> - Added new flag wasm-gc-structref-as-dataref which defaults to true
> and preserves the existing behavior.
> - Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
> - The flag affects static subtyping information between structref and
> arrays and the corresponding cast, test and br_on instructions.
> - Even with the old behavior the name still changed to "structref".
>
> Bug: v8:7748
> Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83697}
Bug: v8:7748
Change-Id: Icb273a6d433c47a372563d0daf68725c6c5b15e3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952514
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83698}
This is a reland of commit 20327d1599
Changed in reland:
- Added new flag wasm-gc-structref-as-dataref which defaults to true
and preserves the existing behavior.
- Passing --no-wasm-gc-structref-as-dataref enables the new behavior.
- The flag affects static subtyping information between structref and
arrays and the corresponding cast, test and br_on instructions.
- Even with the old behavior the name still changed to "structref".
Original change's description:
> [wasm-gc] Ref types: Convert dataref to structref
>
> This change changes the type hierarchy in a non-backwards compatible
> way: dataref is replaced with structref meaning that arrayref is
> no longer a subtype of it.
>
> Bug: v8:7748
> Change-Id: I965267d9ed11ea7c7d7df133cc39ee63e6b5abc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3929041
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83515}
Bug: v8:7748
Change-Id: I2d8dd49dbc56246c087ac93452a87f860ead2195
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945109
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83697}
A circular ownership of ref-counted resources caused the leak as the
wasm::StreamingDecoder stored a callback that contained the decoder in
its scope (needed for the URL).
Bug: chromium:1368609
Change-Id: Ib07b066c92f16b658daa1daf482f71c33a16e89a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942066
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83695}
When we change input to an AssertNotNull node as part of an
optimization, the type of the new input might be incompatible with its
current type. Therefore we need to untype the node to not trigger an
error later.
Bug: v8:7748
Change-Id: Ica560bde908e01785cb5d1d50c20a8951bdaabd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948609
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83694}
Make several changes to template object caching:
* Key the cache on Script rather than SFI, so that entries stay alive
even if the SFI dies (e.g. because its parent is code flushed) but
can be resurrected (because other functions from the same script can
recreate it)
* With the above change, identify the required template object by
comparing both function literal id and feedback slot id.
* Change the cache from a linked list of CachedTemplateObjects into an
ArrayList pointing directly to the template object JSArrays.
* With CachedTemplateObjects being gone, store the function literal id
and slot id directly on the JSArray behind private symbols. Fast
path access to them in the case where the template object has the
expected map, and look them up in a slow path if the map changed
(e.g. because the template object was used as a prototype and
transitioned to a dictionary map).
Change-Id: Id715cb2fd38b9605b8e6ddf5e35336bb4f0300d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900376
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83693}
This removes the deprecated FLAG_* aliases, and switches remaining uses
to the new v8_flags syntax.
R=jkummerow@chromium.org
Bug: v8:12887
Change-Id: Icde494a3819a9b1386c91e44f5d72a55666d9eae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952350
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83686}
Our previous assumption that the receiver is immutable is incorrect in
constructors. Change the current logic (which never generates an
exception phi for receivers, but instead re-uses the parameter slot)
into forcing the receiver exception phi to be allocated (and spilled) in
the receiver parameter slot.
Bug: v8:7700
Change-Id: I1ba92b2e711dc0fcd7c818526b9c199cadcdd3bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948586
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83684}
When not in unicode sets mode, '[' within a class is an ordinary
character (not the beginning of a nested class).
While scanning for capture groups, the flag (/v) was not taken into
account.
Bug: chromium:1374232
Change-Id: I05b9758bedba25633129b12d4634510031d01544
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952253
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83683}
In production we will only compile Wasm code with TurboFan after it has
already been executed via Liftoff. Hence we know that the code is valid,
and can skip validation. This will save some binary size, and (minimal)
run time.
Under exotic circumstances (no Liftoff, Liftoff bailed out, ...) we did
not run validation yet. In that case, run it explicitly.
Note that the {kNoValidation} mode still has the validation checks as
DCHECKs, so fuzzers can find bugs in the new logic.
R=jkummerow@chromium.org
Bug: v8:13361, v8:13371
Change-Id: I2d0896bee44a80a9d09d9c273ec5fdbe9ab8da62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941891
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83676}
In order to drop validation from TurboFan, we need to know which
functions have already been validated when starting TurboFan
compilation. Under normal circumstances, that would be all of them. In a
TurboFan-only configuration, or for new code where Liftoff bails out, we
could need to run validation before TurboFan compilation though.
R=jkummerow@chromium.org
Bug: v8:13361, v8:13371
Change-Id: Ia59bdb1c25e4fc4300ca3d8cfe3ac3caf4985fa1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942090
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83674}
After an error is encounterd during RegExp parsing, indicate that there
is no more work to do.
Bug: chromium:1374042
Change-Id: Ib547a06de855028e862933897930d8ba78f8f320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3950294
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83673}
After the let instruction was removed again, the number and types of
locals stays constant throughout the decoding of a function. Hence store
it in a plain array instead of a ZoneVector. This makes the decoder
smaller and saves bounds checks for the "safe libc++".
R=thibaudm@chromium.org
Bug: chromium:1358853
Change-Id: Iad69aa0cfdc254710e1c2219cfb2c972241ef473
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3944929
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83671}
This CL implements the heavy lifting for re-using block lists:
- On local debug-evaluate, we check if the paused function already
has a block list. If not, we do a full re-parse, calculate the
block lists and stash them in the global map.
- On a context lookup, we do the lookup slightly differently. The
block lists now store "outer" locals, so we need to check the
block list before we advance to the next context, not before we
do the lookup in the current context.
The CL also duplicates the debugger test that checks most of these
shadowing edge cases. While we keep working on the new feature
we still want to check both configurations, but the feature is too
small to warrant a separate bot. Note that the file with the flag
enabled has one additional test case that fails with the old
implementation. Unfortunately it's non-trivial to fix in the old
implementation.
This CL drastically improves performance for conditional breakpoints
as they use local debug-evaluate under the hood. The worst case
example (https://crbug.com/1072939#c15) improves from 6.5 seconds
to 100ms.
R=jarin@chromium.org
Bug: chromium:1363561
Change-Id: I85f3d908d246f0d2e31ed272f4db6a852b9dbc39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3941584
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83665}
Output of type UnsignedBigInt64 can be out of the range of small
BigInts. This CL inserts necessary conversion and checks for it.
Bug: chromium:1371935, v8:9407
Change-Id: I2553679452caa63111b97c89d072dd5fcc98aa7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3939668
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Qifan Pan <panq@google.com>
Cr-Commit-Position: refs/heads/main@{#83661}
