Make LazyDeoptInfo and EagerDeoptInfo both store a
CheckpointedInterpreterState for the bytecode position and
register frame, and make codegen store pointers to these
deopt infos instead of the checkpoint.
This opens the door to using InputLocation for lazy deopts,
same as for eager ones.
Bug: v8:7700
Change-Id: I8ff3056ff72fd9f2288d41769979c5183c3d0972
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563561
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79723}
In DisassembleFunction runtime, function may have available
optimized code and we could directly set the optimized code
for the function like in CompileLazy if it's not compiled,
which avoids calling Compiler::Compile and failed in
DCHECK(!function->HasAvailableOptimizedCode()).
Bug: v8:12762
Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79722}
Traced nodes can contain SMIs, e.g. when base::ScriptValue is
constructed. The CL filters them out when visiting V8->C++ references,
as otherwise it crashes later assuming HeapObject.
Bug: chromium:1029379
Change-Id: Idaafc92d4dc1bd14c7d1a07e2177202a8af336a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555769
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79719}
IBMi does not yet support prefixed instructions, p10 features need
to be disabled until OS support is available.
Change-Id: Idca7d6ebd791b06ef8f1f8419badd1a3db0f277f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562980
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#79718}
For short builtin calls, the builtins are copied on the heap when they
cannot be put close enough to be in range of relative calls. This costs
memory, as the embedded builtins are part of the binary, and mapped from
the binary, and as a consequence shared with all running processes.
Rather than copying the memory, we can remap it at a different address,
avoiding the memory cost. This CL does that, on ARM64 macOS only for
now.
This saves at least ~1.4MiB of memory per V8 process. See below the
output of vmmap <PID>:
[...]
Memory Tag 255 7408308000-740833c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740833c000-7408340000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408344000-7408348000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408348000-740837c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740837c000-740fe80000 [123.0M 0K 0K 0K] ---/rwx SM=ZER
mapped file 740fe80000-740ffe4000 [ 1424K 1328K 0K 0K] r-x/rwx SM=COW ...pp/Contents/Frameworks/Chromium Framework.framework/Versions/102.0.4958.0/Chromium Framework
Memory Tag 255 740ffe4000-7410000000 [ 112K 0K 0K 0K] ---/rwx SM=ZER
The "208K" regions are 256kiB code pages, minus the header and guard
pages, meaning that they are code chunks. The mapped file are the
remapped builtins, showing that they aren't copied, but remapped from
the binary.
Bug: chromium:1298417
Change-Id: Ia30a43e671726d01450a7db0ecb7777b34763053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3553006
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79716}
Lock mutex for shared isolate in global safepoints, such that e.g. the
StringTable can use isolate->heap()->safepoint()->AssertActive() even
for shared isolates.
Bug: v8:11708, v8:12749
Change-Id: I8d99203581dfa2d7225846e19fa981300f88589e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563138
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79715}
Skipped test: https://crrev.com/c/3561199.
This is a reland of commit 6e2c9bb265
Original change's description:
> [serialize] copy bytes for non detachable array_buffer
> in WriteJSArrayBuffer when array_buffer is not in
> array_buffer_transfer_map_
>
> According to https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal
> steps 13.3.2-4, should normally serialize array buffer which
> is not detachable.
>
> Bug: v8:12703
> Change-Id: I4554c5d07ae85e1a96a728ebba04c6a071575f6f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518910
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79466}
Bug: v8:12703
Change-Id: I1ad1b8159ac7b13011831a4590e8577e954db946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557689
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79714}
Since the new space is always empty after a full GC, the old-to-new
remembered set is also always empty after a full GC. This means we can
get rid of the sweeping_slot_set_.
This slot set was used to allow the main thread to insert into the
old-to-new remembered set non-atomically. The sweeping slot set was
owned by the sweeper, which deletes slots in free memory from it. The
main thread would start with an empty old-to-new remembered set. After
sweeping both slot sets are merged again.
The sweeper now needs to behave differently during a GC. When sweeping
a page during full GC, the sweeper needs to delete old-to-new-slots in
free memory.
Outside of the GC the sweeper isn't allowed to remove from the
old-to-new slots anymore. This would race with the main thread that adds
slots to that remembered set while the sweeper is running. However,
there should be no recorded slots in free memory. DCHECKing this is
tricky though, because we would need to synchronize with the main
thread right-trimming objects and at least String::MakeThin only deletes
slots after the map release-store.
Bug: v8:12760
Change-Id: Ic0301851a714e894c3040595f456ab93b5875c81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560638
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79713}
Add an array of canonical rtts on the isolate. Each wasm instance
copies its rtts from there, based on the type index -> canonical index
mapping in the module.
Bug: v8:7748
Change-Id: I0958686c51ecab15a3215a0da3bee1ad6d543cb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548821
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79712}
The current safety margin between the JS stack limit and the actual
boundary of the stack space reserved by the simulator can be overrun by
a large frame.
Raise this margin to 4KiB, corresponding to the "large frame" threshold.
This ensures that the stack check is executed before the frame is
allocated if the frame is larger than this margin.
R=clemensb@chromium.org
Bug: chromium:1308333
Change-Id: I3e1a51bb36c630c7e37e58679971392dada2a83e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560435
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79711}
While this field isn't used, inititialize it to null.
Bug: v8:11708
Change-Id: I9698e73183f49ef54b8978383e1406e5cf765c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562982
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79710}
... in JSObject::DefineOwnPropertyIgnoreAttributes().
Don't execute interceptor again if it declined to handle the operation.
Bug: chromium:1311641
Change-Id: If61ed40665ff7d81e96fa6bf29bbb5dfbeadfcc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562979
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79707}
This reverts commit 3ce690eef2.
Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188
Original change's description:
> [osr] Basic support for concurrent OSR
>
> This CL adds basic support behind --concurrent-osr,
> disabled by default.
>
> When enabled:
> 1) the first OSR request starts a concurrent OSR compile job.
> 2) on completion, the code object is inserted into the OSR cache.
> 3) the next OSR request picks up the cached code (assuming the request
> came from the same JumpLoop bytecode).
>
> We add a new osr optimization marker on the feedback vector to
> track whether an OSR compile is currently in progress.
>
> One fundamental issue remains: step 3) above is not guaranteed to
> hit the same JumpLoop, and a mismatch means the OSR'd code cannot
> be installed. This will be addressed in a followup by targeting
> specific bytecode offsets for the install request.
>
> This change is based on fanchen.kong@intel.com's earlier
> change crrev.com/c/3369361, thank you!
>
> Bug: v8:12161
> Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79685}
Bug: v8:12161, chromium:1312188
Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983
Auto-Submit: Adam Klein <adamk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79702}
This reverts commit d368dcf4ae.
Reason for revert: https://crbug.com/1312188
Original change's description:
> Refactor OSROptimizedCodeCache
>
> Tweak a few names, remove a few GetIsolate calls, other minor
> usability refactors.
>
> It may be worth taking a closer look at the impl in the future,
> currently the design choices don't seem ideal (see the added TODO
> on top of the class).
>
> Bug: v8:12161
> Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79687}
Bug: v8:12161, chromium:1312188
Change-Id: Ieb3a91682845a23536fdfdf3208af74b3c6585f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564989
Auto-Submit: Adam Klein <adamk@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#79700}
These tests are too slow to be generally run.
Bug: v8:12741
Change-Id: I142a81a90558942a61b8582756b9227e6d8d634e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3558558
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79697}
In JSCallReducer::ReduceArrayPrototypeShift, when disable
FLAG_turbo_loop_variable, typer cannot infer loop phi variable
is in [1, kMaxCopyElements-1], and will break in representing
kRepFloat64 (Range(1, inf)) to kRepWord64 when converting
input for kLoadElement. So we need to add type guard for loop
variable. And we need to use loop phi variable when using
NumberLessThan to check terminate and updating phi loop variable,
otherwise which will break inducing variables in LoopVariableOptimizer.
Bug: v8:12632, chromium:1308241, chromium:1308029, chromium:1308087
Change-Id: I9f96e696f1103f39e633890b17b87bfb28b1dbc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3546577
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79695}
As a follow-up of
https://chromium-review.googlesource.com/c/v8/v8/+/3481475,
this renames a few more operations related to property stores to keep
them consistent and adds comments to explain about what they do.
Summary of the renamed identifiers:
- SetPropertyInLiteral -> CreateDataProperty: this implements
[[CreateDataProperty]] in the spec which does [[DefineOwnProperty]]
instead of [[Set]], so rename for clarity.
- IsStoreIC(), IsStoreICKind() -> IsSetNamedIC(), IsSetNamedICKind():
these only check whether the feedback kind is kSetNamedSloppy or
kSetNamedStrict, so the scope can be narrowed.
- StoreMode::kOrdinary -> StoreMode::kSet: this implements [[Set]]
in the spec and is used by both KeyedStoreIC and
StoreIC to set the properties when there is no feedback.
- StoreMode::kInLiteral -> StoreMode::kDefineKeyedOwnInLiteral:
this implements [[CreateDataProperty]] while expecting the receiver
to be a JSObject created by us (the `InLiteral` part). Prepend
`DefineKeyedOwn` to it so that it's more aligned with other
StoreModes - it should be possible to just merge this into the
more generic StoreMode::kDefineKeyedOwn later.
- KeyedStoreGenericAssembler::SetProperty ->
KeyedStoreGenericAssembler::StoreProperty: these helpers are used by
both define and set operations, distinguished with the StoreMode,
so rename it to the more generic StoreProperty.
Bug: v8:12548
Change-Id: Iccef673c1dc707bbdbf010f02f7db1e9ec32b3e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557690
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79694}
This is a reland of commit e76ad5c6d9
Changes compared to original:
- Move invocation of LAZY_INSTANCE_INITIALIZER to a static global
variable, as some builds were failing with a function-level static.
- Drive-by: Improve documentation a bit.
Original change's description:
> [wasm-gc] Implement isorecursive canonicalization
>
> This implements isorecursive canonicalization for static types.
>
> Not implemented in this CL:
> - Runtime type canonicalization.
> - Cross-module signature canonicalization for purposes of call_indirect.
>
> Bug: v8:7748
> Change-Id: I6214f947444eea8d7b15a29b35c94c3d07ddb525
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541925
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79665}
Bug: v8:7748
Change-Id: I493fba1906491762f7d8bae50108e3e4a743391d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560480
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79692}
Deprecate signature checks in
* Template::SetNativeDataProperty
* ObjectTemplate::SetAccessor
These are not used in Chrome and require some complicated check in the IC code, which we want to remove.
Change-Id: I413fafc8658e922fd590e7fe200600a624f019a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557253
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Stephen Röttger <sroettger@google.com>
Cr-Commit-Position: refs/heads/main@{#79689}
Nodes can now hold a LazyDeoptSafepoint which stores the frame state in
case they trigger a lazy deopt. OpProperties have a new CanLazyDeopt
bit, and codegen emits a safepoint table entry + lazy deopt for all
nodes with this bit. Also, we now check the deoptimized code bit on
entry into the maglev compiled function.
An example use of these lazy deopts is added as a PropertyCell fast path
for LdaGlobal, which adds a code dependency on the property cell.
Bug: v8:7700
Change-Id: I663db38dfa7325d38fc6d5f079d263a958074e36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557251
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79688}
Tweak a few names, remove a few GetIsolate calls, other minor
usability refactors.
It may be worth taking a closer look at the impl in the future,
currently the design choices don't seem ideal (see the added TODO
on top of the class).
Bug: v8:12161
Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79687}
This CL adds basic support behind --concurrent-osr,
disabled by default.
When enabled:
1) the first OSR request starts a concurrent OSR compile job.
2) on completion, the code object is inserted into the OSR cache.
3) the next OSR request picks up the cached code (assuming the request
came from the same JumpLoop bytecode).
We add a new osr optimization marker on the feedback vector to
track whether an OSR compile is currently in progress.
One fundamental issue remains: step 3) above is not guaranteed to
hit the same JumpLoop, and a mismatch means the OSR'd code cannot
be installed. This will be addressed in a followup by targeting
specific bytecode offsets for the install request.
This change is based on fanchen.kong@intel.com's earlier
change crrev.com/c/3369361, thank you!
Bug: v8:12161
Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79685}
When starting a global safepoint, it could happen that one isolate is
waiting/blocking in the event loop, which prevents this isolate from
reaching a safepoint. As a consequence we therefore deadlock when
performing the safepoint. We can solve this by simply posting a task
for each isolate that when run performs a safepoint check.
This CL also renames IncludeMainThreadUnlessInitiator to
ShouldIncludeMainThread.
Bug: v8:11708, v8:12645
Change-Id: Ide956b3c39b350c2bb0279a7dd94ff79cb9d771b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555771
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79675}
