The bytecode can be flushed and/or the function can be
compiled and installed before the interruption to install
the new batch of compiled baseline code.
Bug: v8:12415, v8:12054
Change-Id: I092c8e0f31735119e6b2c6c46ce97ba8a4cdc91e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302788
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78091}
Some of the JumpIf Bytecode Handlers will load the jump offset from
bytecode array or constant pool before checking whether the condition is
matched, and this jump offset is unused if the jump not actually happens.
This CL move the Load operations to the branch on which the condition is
matched.
Bug: v8:12431
Change-Id: I3cb2fa7447ee2a9cb514148efb605617f95b1b68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300994
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78088}
Between the loop entry and the Dequeue call, another
thread might exhaust the queue itens and the Dequeue
call will return false without setting the job.
Bug: chromium:1272009
Change-Id: Ia254d97de36395676f069c100f46747b41483783
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300130
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@{#78084}
Liftoff is also fixed to make sure r0/ip don't get used as
scratch as they might be already used as offset registers.
Change-Id: I8b5636b805acdb7df12af4a7a2f2868bf5889cd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3298254
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78076}
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 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}
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: I35713938ff80f43a763470f8bdf7e242439080f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297903
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78066}
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}
Make it an enum class too, and fix all the enums to follow style guide.
Fixes a -Wshadow warning, NONE shadows PropertyAttributes::None.
Bug: v8:12244,v8:12245
Change-Id: I9a8181a35d5690a32a6ce58587f0d8704aa1ab40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291696
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78062}
When a LocalHeap is destroyed, we update (publish) the changes
in the TypedSlots, this need to be protected by a mutex, since
we may read the RecordRelocSlot in a different thread.
Bug: v8:12054, v8:12411, chromium:1272364
Change-Id: Id1684dad3ed9e02c597099c440d1fbfdbd8c47ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297892
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78059}
The fix in https://crrev.com/c/3283620 doesn't work, it was meant to be
a general way to fix shadow whenever ASM_CODE_COMMENT is used, by
appending the current line, via __LINE__ macro to the variable name.
However, __LINE__ is not expended correctly when it is directly part of
a variable name.
To fix the shadowing, we use UNIQUE_IDENTIFIER to give unique names.
Bug: v8:12244,v8:12245
Change-Id: I7b9b9da74d62023ac631ff0876f41e80971e2f09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291804
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78058}
This CL improves --track-retaining-path with incremental marking:
* Retainers need to be cleared *after* the GC and for full GCs only.
Otherwise a scavenger that runs during incremental marking would
clear all retainers.
* Register marked root objects in IncrementalMarking::MarkRoots with
retaining_root_.
Change-Id: I18ab9da48fb7ac45f9ec0826334fd338dc202edc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297893
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78056}
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}
This is an unused overload, which doesn't add any value to keep around.
Bug: none
Change-Id: I6e004e28f6ec8d4c8de87a1e86d331a624694659
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297896
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78052}
This CL optimizes ByteReverse 16/32/64 ops on PPC<10 as
well as PPC_10_PLUS.
A 32bit sign extension is also added to `ByteRev32` in codegen.
Change-Id: I6379ac4222f3574ab226971546238142039fe977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3298308
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78048}
With dynamic tiering, caching is triggered multiple times as there is
no single event anymore that triggers when the module should be cached.
This CL adds a counter for the number of times caching is triggered.
This counter can indicate whether our current caching heuristics are
good or should get adjusted.
R=thibaudm@chromium.org
Bug: v8:12281
Change-Id: I8ed9ed73a556d11df643c31ec6d20760a257e0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295578
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78045}
This CL adds `can_use_compiled_module` parameter to
WasmStreaming::Finish() that is used by Chromium
https://chromium-review.googlesource.com/c/chromium/src/+/3282643
to invalidate compiled module bytes after SetCompiledModuleBytes().
Bug: chromium:1260939
Change-Id: Iebf0e8615c27c8622721777c664b06a53fb9ee91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297548
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78044}
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}
The list of to-be-finalized objects can grow significantly. While
running Speedometer2, the metadata that stores to-be-finalized objects
can be the second largest contributor to heap consumption (overall
taking up 2.6MB, checked with heaptrack).
The CL changes the list to be stored inlined in HoH, if cage-heap is
enabled, rather than in a separate vector.
Bug: chromium:1249550
Change-Id: I04a0c84d118655fa6ff8e2440423e802cd722842
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295448
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78038}
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}
For large working set, the sweeper metadata can significantly increase.
Currently, the backing of swept_unfinalized_pages never gets freed,
which causes about 300KB of memory be occupied (checked on
Speedometer2). The CL makes sure to shrink (actually free) the backing
after each GC cycle.
Bug: chromium:1249550
Change-Id: I7c7e5248983960a498afc252a344fa71cb1444c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295347
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78029}
Many safepoint tables do not contain any deoptimization info and/or no
callee-saved registers. Do not emit empty fields for all entries in this
case.
This often shrinks the size of the encoded safepoint table by more than
50%.
Drive-by cleanups:
- Rename fields of the safepoint table entries to clarify their meaning
("tagged slots" instead of "bits", "tagged register indexes" instead of
"register bits").
- Include the PC in the decoded {SafepointEntry} to make it the single
source of truth.
R=jkummerow@chromium.org
Bug: v8:12401
Change-Id: If5c24a688a434842ed3b6427f5f1f3ea9232173a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289173
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78021}
With dynamic tiering, not all functions get compiled with TurboFan,
and not all functions can therefore get cached. With this metric we
want to keep track of the time needed to compile missing functions with
Liftoff.
R=jkummerow@chromium.org
Bug: v8:12281
Change-Id: I1f2de3e1f6b004477985df5d2116f69371528c3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289178
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78020}
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}
Once CppHeap moves away from EmbedderHeapTracer, it can no longer be
returned by Isolate::GetEmbedderHeapTracer. Blink currently uses
GetEmbedderHeapTracer to trigger GCs. This CL introduces a variant of
Isolate::RequestGarbageCollectionForTesting to replace that.
Bug: v8:12407
Change-Id: I099989f55291a0daab7d2051072dedddef58dd40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293413
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78015}
Instead of just DCHECKing that we are in a safepoint in
Snapshot::Create, pass the GlobalSafepointScope as argument.
Bug: v8:11708, v8:12377
Change-Id: Ia856c27b92223bf3a96fe6946b86e4625f3a1e0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295342
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78014}
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}
Starting an incremental GC when it is not supported is not allowed but
trying to finalize one when it might be unknown whether it's supported
or not should be legal.
In such cases, finalization would immediately bail out since there is no
active gc.
Bug: chromium:1272076
Change-Id: If5aaaa130dc55474d3fc3afcd7039880a2c11333
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293411
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78010}
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}
PPC and S390 implement vsel slightly differently which
is also reflected on the simulator.
Change-Id: Iec5e49bfae09d8bf15149e5ab149b82971271b24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293409
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78002}
Previously, an allocation from a separate thread could grab the
just-released region and make it accessible before the regions
permissions are changed to kNoAccess at the end of ReleasePages.
Bug: v8:12414
Change-Id: I98c8f8e3df76d4a44c357ddab107cfeff20049b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293083
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77997}
When starting incremental marking from an allocation observer, the
DCHECK for AllowGarbageCollection::IsAllowed() fails. We need to
explicitly allow this here in order to use SafepointScope.
Bug: chromium:1271659, v8:11708, v8:12413
Change-Id: I8607a82faed50f8dfffce1e495fb5e715a47bc1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293086
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77996}
In such a case, we must post-process all aborted pages. The early
bailout assumed that not pages are aborted before trying compaction.
Bug: chromium:1271229
Change-Id: I4c5998b9d1c7974f7d1d25a6729f42d5690a5759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289171
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77987}
The entries contain more than just deoptimization info. Thus rename them
to "entries" and use "EntryBuilder" instead of "DeoptimizationInfo".
Drive-by: Remove the redundant {emitted_} field, just check if
{offset_} was initialized.
R=jkummerow@chromium.org
Bug: v8:12401
Change-Id: Ifedc265dc27dd6817b731d9e24a1d8654edc99de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291310
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77985}
Verify certain properties when emitting safepoint tables:
- entries are ordered by PC,
- trampoline PCs are also in order,
- all trampoline PCs come after all regular PCs, and
- an entry with a deopt index also has a trampoline PC set.
Drive-by: Slightly simplify logic in {UpdateDeoptimizationInfo}.
Drive-by 2: Inline IsIdenticalExceptForPc into the only caller, and
further simplify the logic there.
R=jkummerow@chromium.org
Bug: v8:12401
Change-Id: I8ea41b1628dceb914191f23165c8dccb79f9204c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289162
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77983}
We should not assume that the embedder can run with concurrent marking
even though we just finalize the GC at this point.
Bug: chromium:1271371
Change-Id: I3d3a45e4283dcae9c6fdd1a467158254914868c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289169
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77982}
A SafepointScope might need to block for a shared GC initiated from
another client isolate. This means that anytime we create a
SafepointScope a shared GC may run. This CL adds a DCHECK to ensure
AllowGarbageCollected::IsAllowed() holds for each SafepointScope.
So far this DCHECK was only run in the less likely event that a
SafepointScope actually runs a shared GC. Which is technically good
enough but it is easy to miss use cases of SafepointScope where this
does not hold.
Bug: v8:11708, v8:12377
Change-Id: I30cc33c05ebe4835430e1d699a86079810523858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289625
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77976}
Many callers already pass an int, so there is no point in storing as an
uint32_t internally. The style guide also recommends int as the general
data type for integers, even if it's statically known that only positive
values will occur.
R=jkummerow@chromium.org
Bug: v8:12401
Change-Id: I6067139f514895f925d1c536112b4cb5c2c24a36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289157
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77975}
Refactor s.t. we now compact the DependentCode weak fixed array both
when adding new entries and when marked for deopts.
Bug: v8:12397
Change-Id: I842f3369644e88cc0b98a1f1371259c920cc8bbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291320
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77973}
Using a map to store node states in Int64Lowering has proven slow.
Therefore, we change the data structure to a vector indexed by node ids.
Bug: v8:12166, chromium:1271179
Change-Id: I13b78091fe1a6a13c26afd706d3839b0c04390f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291308
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77971}
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}
When compiling code off-thread in the large code space,
we need to register the chunk in the isolate using
AddCodeMemoryChunk.
In the main thread, this is done when AllocateRaw calls
NotifyOldGenerationExpansion.
Bug: chromium:1269315, v8:12054
Change-Id: I46ea5c9cdcd063708292dd49aac6d39091e11ba4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289151
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77968}
Raise an exception if CallFunction is invoked with a class constructor.
The check was initially removed in [1] but there are cases where we
could end in CallFunction with class constructors from optimized code.
[1] https://crrev.com/c/3186434
Bug: chromium:1271384
Change-Id: I0d700c4b1d117334c1c4c14719e24cd1f2c5e3a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291313
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77967}
Undetectables are always callable in V8, so the previous type check
didn't make sense.
Bug: chromium:1267230
Change-Id: Idb557bb05ee4c3b332d1fe61b40557122660261a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291303
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77966}
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}
This is in anticipation for sharing internalized and
in-place-internalizable strings across Isolates. When such strings are
shared, background compilation threads need to be able to allocate
strings in the shared old space.
Bug: v8:12007
Change-Id: I93179c9674cc16e5a6125049d20e61495bc1f3a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283615
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77959}
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}
fma_instr is now no longer required
Change-Id: Iab47aa6afcc53c78acf15c7ab71f6b9ba45263c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3286003
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77955}
For streaming compilation, include the source URL in tracing, to
help identifying problems with caching.
R=ahaas@chromium.org
Change-Id: Iefda71890024a4fc9ec933c34c5870ba697bbff9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289148
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77950}
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}
This is a reland of 9b5f398554
Reland fixes:
* Store a Handle instead of a raw pointer in the scope, to make sure
the saved object stays alive.
Original change's description:
> [runtime] Reset clobbered argument in DefineClass
>
> The caller of DefineClass may not expect its arguments to be mutated, so
> add an arguments mutation scope which resets the argument clobbered by
> DefineClass.
>
> Bug: chromium:1268738
> Change-Id: I03e9cd82535ca1f83353012a92e80f822566e64e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283077
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77921}
Bug: chromium:1268738
Change-Id: I934ba2063bf2b0e66a3c42f274419ddd178e4b54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289146
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77945}
This makes --experimental-wasm-gc imply --wasm-speculative-inlining,
which in turn implies --wasm-inlining and --wasm-dynamic-tiering as
prerequisites.
The former implication is weak, i.e. can be overridden on the command
line.
Bug: v8:7748
Change-Id: Iedc7c9916947f26e17bdd29dbf3b413dbaa05e6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275571
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77944}
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}
This fixes a -Wshadow warning with an inline enum in regexp-compiler.cc.
Bug: v8:12244,v8:12245
Change-Id: I8b53a94a1945addb958b230abe01b10d4533edae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3285732
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77935}
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}
These helper macros declare the same variable (asm_code_comment),
when used in 2 scopes (one inside another), we get a shadow variable.
In all the current usages, we always have a ASM_CODE_COMMENT in
the outer scope (which adds a comment with the function name),
and in the inner scope uses a string. It is sufficient to fix these
cases by giving the first case (function name) a different variable
name.
Bug: v8:12244,v8:12245
Change-Id: Ib23d9796f10937f27ce29913c0fa648501edbda8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283620
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77930}
- Rename --skip-snapshot-checksum to --verify-snapshot-checksum to
avoid double negations in most of the code
- Conditionally create and verify checksums in SerializedCodeData
- Remove unused Deserializer::GetChecksum
Bug: chromium:1270752
Change-Id: I8360e0dd5f25dac68bf68909155771b302184a4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284883
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77925}
Register printing under --trace-ignition used register operands to
decide which register to print. But, for short Star bytecodes (Star1,
Star2, etc) the register is implicit in the bytecode. Add support for
these.
Change-Id: I788ffd729e251f2c8795b5660ac773329502bb5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283071
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77922}
The caller of DefineClass may not expect its arguments to be mutated, so
add an arguments mutation scope which resets the argument clobbered by
DefineClass.
Bug: chromium:1268738
Change-Id: I03e9cd82535ca1f83353012a92e80f822566e64e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283077
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77921}
Previously the code range could be allocated close but still outside
of the "short builtins call" region which would enforce copying of
builtins blob into the code range.
This CL ensures that the calculated hint address takes the required
base alignment into account and thus allocates the core range inside
of preferred region (see Isolate::GetShortBuiltinsCallRegion()).
Bug: v8:11880
Change-Id: I3cbd6a81501efd420063b963a8c4b5c328ae0785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283065
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77919}
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}
Port: 255aaed95b
Original Commit Message:
The receiver is now always included in the actual argument
count and the formal parameter count.
kDontAdaptArgumentsSentinel is changed from UINT16_MAX to 0
to preserve the maximum allowed declared parameters.
The build flag activating the changes is not set for any
architecture yet.
Bug: v8:11112
Change-Id: Ib106775014a886da80684dcb83ed704bb898a244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3271635
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77907}
Let Heap::MakeHeapIterable() and Heap::FreeLinearAllocationAreas() also
handle the new space to be more uniform between spaces. Also removes
Heap::EnsureFillerObjectAtTop() in favor of
NewSpace::MakeLinearAllocationAreaIterable().
Bug: v8:10315
Change-Id: I7d28c1e95e433c4bc5a4a1a1f3aa8d71c43b8887
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281926
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77905}
This change allows clients of the RegionAllocator to provide callbacks
that are invoked when regions are split or merged.
This will later be needed on Windows when a RegionAllocator is used to
manage a placeholder mapping as these need to be split and merged (using
the VirtualFree API) as well.
Bug: chromium:1218005
Change-Id: I228b41bdb43c4a9ef0db04de9b121dea6b5f12f9
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264287
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77903}
Port commit 3e3a027da1
Beside, some registers are changed to callee-saved, and the previous
related save and restore operations are removed.
Bug: v8:11382
Change-Id: Ic3161f8173771c1b7c190c77cbaf2534f52ec422
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281673
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Auto-Submit: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#77902}
Code pages need to be swept on the main thread for now. Originally this
was done to prevent RWX on code pages, but there might be more other
smaller issues like the linked bug. Most likely this restriction isn't
a problem for concurrent SP at the moment, so stick with this
invariant for now.
Bug: chromium:1269558, v8:12054
Change-Id: Icf7a7ce9714b9ef07b1a5070f0b0dd963b6d3011
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3279682
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77901}
This CL adds Heap::FreeLinearAllocationAreas to free all local
allocation buffers (LABs). We use this to give up LABs for a local GC.
The second method Heap::FreeSharedLinearAllocationAreas is used to free
all LABs in the shared heap for shared GCs and in the future also on
isolate shutdown.
Bug: v8:10315
Change-Id: Ie5cbb68c95fae027055aeaf4458473b04b15b18c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3279681
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77900}
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}
With eager compilation, CompilationEventCallbacks get released when all
compilation units in the compilation state are finished. This is
possible because no future compilation event could get triggered after
that. With dynamic tiering, though, the {FinishedCompilationChunk} event
can trigger repeatedly, even after all compilation units finish at some
point in time, as dynamic tiering can create new CompilationUnits. As
a temporary fix, CompilationEventCallbacks don't get released when
dynamic tiering is enabled.
This CL fixes this issue by turning the callback from an std::function
into a class, and adding a second function to the class which indicates
whether the callback can be released when all compilation units in the
compilation state are finished. Thereby all callbacks can be deallocated
except the ones like the code caching callback which waits for the
{FinishedCompilationChunk} events.
R=jkummerow@chromium.org
Bug: v8:12289
Change-Id: I0f73f4bd2dffe644c9a26c274cb52ac6fa49ab67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264288
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77890}
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}
The entered contexts stack must be in sync with the flags stack.
Bug: chromium:1269225
Change-Id: Ibb522286b47866d5f13aaec1a0a02914c13a5545
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3279680
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77882}
When incrementally marking a non-shared heap, shared values should not
be marked. Similarly, non-shared values should not be marked when
incrementally marking a shared heap.
Bug: v8:11708
Change-Id: Iecd799e7e3060e5fb3897b8be0c4e8158d9ff57f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3278673
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77881}
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}
Switching stack affects all instances, therefore make the active
continuation a root object instead of an instance field.
Bug: v8:12191
Change-Id: Ia521bf4e7c3cbca035f916e47804c2f75bbd8f18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268296
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@{#77876}
This shadows ATOM used in js-regxp.
Making this an enum class requires changing a lot of different places.
Atom is an Intel brand name, so INTEL_ATOM kinda make sense.
Bug: v8:12244,v8:12245
Change-Id: I80be342488328cde5aaca36f900375d2fb381253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3276926
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77875}
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}
When closing a concurrent allocator, for instance when closing a
LocalHeap, we need to make the LAB of the code space iterable.
We add then a CodePageMemoryModificationScope to allow
code space modification.
Bug: v8:12054
Change-Id: I438d7c1a50694930b7558dec2dd552bec22b7552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277887
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77871}
Speculative fix for a data race involving memory measurement. For memory
measurement we use JSGlobalObject::native_context_unchecked in
NativeContextInferrer::InferForJSObject when trying to infer the
NativeContext for a JS object from a concurrent marking thread. This
load can race e.g. with the context deserializer running on the main
thread. Fix this race by making the load relaxed atomic.
Bug: chromium:1269681
Change-Id: Id04a92572d7d722594b2f8465e579b7231e54e29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277885
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@{#77870}
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}
The DCHECK ensures that a page that is going to be destroyed is not
anymore part of the vector of pages of a space. This DCHECK runs while
a potential concurrent sweeper task may add a page for a live object
to the vector, resulting in a broken iteration. Use the pages lock to
fix this.
Bug: chromium:1268969
Change-Id: Ice87026957b3e6b5d36cf28293f7aa6901e96ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277132
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77867}
Port 9a900169f8
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.
Bug: v8:12373
Change-Id: Ib824db839219307ba390a6dc3c697bedb792046f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275135
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77862}
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}
My previous change https://crrev.com/c/3160299 introduced a runtime
CHECK that crashes the process if V8 attempts to read a deoptimization
literal which has been cleared. That CHECK is indeed crashing the
process.
It appears that the trouble arises in cases where the deoptimization
data indicates that an object should be materialized as needed. In those
cases, one of the deoptimization literals is the Map to use when
materializing the object. It is possible to reach a part of the code
that requires the materialized object, and therefore the Map, without
there being any other owner of that Map. This is in contrast to most
other deoptimization literals, which are logically equivalent to omitted
values from the stack frame and therefore can't be reached without a
real owner somewhere to keep them alive.
To fix, I propose referring to Maps strongly from the deoptimization
literals. The cases I investigated in v8:4578 didn't involve Maps, so I
believe that the observed memory leaks are still fixed with this change.
Bug: chromium:1268681, chromium:1268683, chromium:1268825, v8:12300
Change-Id: Ifd32a7f9cc29e0384650013ab16e05646bf57895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272880
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77857}
The check is a simple shortcut, but this is not safe in multithreading.
In a multi-threaded situation, if a CodePageCol**Scope is open while
a CodeSpaceMem**Scope is already opened, the result is a noop.
If the latter finishes first, then we would decrement a wrong
depth in ~CodePageCollectionMemoryModificationScope.
Bug: v8:12054
Change-Id: I7e1016628ffbd37b343ea130eb8d7d8e60abec98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275562
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77849}
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}
... by
1) using platform-specific kMaxPCRelativeCodeRangeInMB constant
instead of fixed 2GB for computing a region around embedded builtins
from which the builtins could be reachable by pc-relative call/jump
instructions,
2) remapping builtins into the code range if the latter happened to be
allocated too far from embedded builtins (so that the pc-relative
calls/jumps can't reach the embedded builtins blob).
Bug: v8:11880
Change-Id: I3c8df6836a8f0156d5360edd9c4ae8c295ec7100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270543
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@{#77837}
Force-inline the HandleScope constructor and destructor, and
add branch hints for two commonly-mispredicted branches. This
moves the overall JetStream2/cdjs score by roughly 4% on d8. I
suspect no change will be visible in chromium builds (with PGO).
Bug: v8:12196
Change-Id: I0fd7b67aa554876d2dad2d706b874df21dbb72e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270542
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77836}
This introduces a stack frame cache on the V8Debugger level, which
de-duplicates StackFrame instances based on their scriptId, line and
column number.
This greatly reduces the memory pressure when debugging huge Web
applications that have a lot of async activity (and potentially
have scripts with huge URLs). This is guided by the observation
that even in huge applications, there are only a very limited
number of call sites that initiate async activity and hence we
only have a limited number of distinct StackFrames to worry
about (despite having to maintain a large number of async stack
traces overall).
As a nice side effect, this CL also greatly reduces the negative
performance impact of collecting async stack traces in these
huge applications.
Generally speaking this is mostly duct tape however, and we might
want to follow up with changes to make capturing (and storing)
stack frames even cheaper.
Fixed: chromium:1268436
Change-Id: Ib212b3c97dce2bb7ca47d5875d45cf20b9b97afe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272577
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77835}
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}
Don't emit modsd, modud, modsw, moduw if Power proc. version is less
than 9.
Change-Id: I20a33930c5887921cf1943558b3ab6ac8d8a53ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3271636
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Cr-Commit-Position: refs/heads/main@{#77830}
While compiling concurrently, we change the permissions of the page
containing the new code object to RWX, so the main thread can continue
executing a potential code in the same page.
If no thread is compiling the new code, we change the permissions
of all pages affected back to RX.
We also initialises code object page to immediately RWX by default.
Otherwise, a new code could be allocated in the same page, it will call
UnprotectAndRegister, and since write_unprotect_counter_ is now at
least 2, the code ignores the permission change. We then sigfault
when trying to run the new code.
Change-Id: Id18bcb9a44843b4ff747b1e4ac91913e80b74d80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257606
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77827}
The feature is controlled by a boolean flag on Isolate, so there's no
need to keep the flag read-only.
Bug: v8:11527, chromium:1241665
Change-Id: I377452fed10b319a4a512c090706c754603c2ae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270547
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77820}
The LocalAllocationBuffer (LAB) doesn't need to be iterable, when the
heap needs to be iterable we have explicit calls to `MakeIterable()`
anyways for the LABs.
Also creating that filler object initially isn't enough, we would need
to do this after each and every allocated object.
Change-Id: Iedb011205d7590a75ea17d518e78e340f1d4b63d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270546
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77819}
