Splitting off cosmetics and unrelated test refactorings from a larger
CL reworking traced global handles.
Bug: v8:13141
Change-Id: I675cdbd4898346ab55b0db65d53e992f2eb95744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816671
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82295}
StepOrigin is enough to infer the right completion action: Either
finalization by task (for StepOrigin::kTask) or stack guard
(for StepOrigin::kV8).
Only tests with StepOrigin::kV8 were violating this but they also just
pass when enabling the stack guard.
Bug: v8:12775
Change-Id: I5df50198d8e3612ee97142f84bd497820a5cec78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816664
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82294}
This reverts commit b1020a4345.
Reason for revert: Causes timeout for `condition-workers`: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/40516/overview
Original change's description:
> Reland "[shared-struct] Add Atomics.Condition"
>
> This is a reland of commit e2066ff6bf
>
> Changes since revert:
> - Rebased against c991852491, which
> uses the external pointer table for the WaiterQueueNode stored
> in the state field when compressing pointers. This relaxes
> the alignment requirement of the state field to be 4-bytes when
> compressing pointers.
> - Moved the state field into the JSSynchronizationPrimitive base
> class, since alignment and padding can now be made simpler.
>
> Original change's description:
> > [shared-struct] Add Atomics.Condition
> >
> > Bug: v8:12547
> > Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> > Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Adam Klein <adamk@chromium.org>
> > Commit-Queue: Shu-yu Guo <syg@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#81734}
>
> Bug: v8:12547
> Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82278}
Bug: v8:12547
Change-Id: I27c2aeb131f1b68c2240323189db88d552aa92f9
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3817187
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82292}
Avoid terminating from another thread in some thread termination
unit tests.
Change-Id: I0f66e49f1f4e7e3d6ec4c614c2cc1afc9fdb0a22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3816663
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82284}
This is a reland of commit e2066ff6bf
Changes since revert:
- Rebased against c991852491, which
uses the external pointer table for the WaiterQueueNode stored
in the state field when compressing pointers. This relaxes
the alignment requirement of the state field to be 4-bytes when
compressing pointers.
- Moved the state field into the JSSynchronizationPrimitive base
class, since alignment and padding can now be made simpler.
Original change's description:
> [shared-struct] Add Atomics.Condition
>
> Bug: v8:12547
> Change-Id: Id439aef9cab3348171a23378cdd47ede5f4d7288
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630350
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81734}
Bug: v8:12547
Change-Id: I638304c3d5722c64bd04708ed4cf84863cdebb81
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng,v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763787
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82278}
Use a single SBFX instruction for Word64Sar(ChangeInt32ToInt64(x), imm)
when possible.
Using PGO, this improves Speedometer2 by 0.4% on a Cortex-A55 machine,
and 0.27% on a Neoverse-N1 machine.
Change-Id: I6fea5e473f0f0869f8f6cebd9a4e61bb2fc6e9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807586
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82277}
noextern is the abstract null type for the extern type.
Bug: v8:7748
Change-Id: I03ac0daf3051f479e096f3d05f4fa7cbf03968f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82276}
nofunc is the abstract null type, the equivalent of none but for the
function type hierarchy.
none and nofunc (and later on noextern) all can only represent a null
value, however their nulls are distinct (as there isn't any subtype
relationship between them).
Bug: v8:7748
Change-Id: Ic5ae502cc21a581ca2e0f5abc46139435d950af9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3805884
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82274}
This change removes the subtyping between funcref and anyref.
Currently, nullref (ref null none) is still a subtype of funcref and externref.
This has to be adapted in a follow-up change introducing nullexternref
(ref null noextern) and nullfuncref (ref null nofunc).
Bug: v8:7748
Change-Id: I77a1b3fef387faf710f7bf7bf9d4655fb600ffdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804253
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82267}
... - a code range size agnostic version of InterpreterEntryTrampoline
builtin. The new builtin is fully compatible with the default version
and used as a template for creating interpreter entry trampoline
Code objects when --interpreted-frames-native-stack is enabled.
This CL introduces a new assembler option "position_independent_code"
which affects the way builtin calls are generated.
This mode is enabled only for InterpreterEntryTrampolineForProfiling.
Motivation:
* InterpreterEntryTrampoline uses RelocInfo::CODE_TARGET for calling
other builtins which requires the code range to be small enough to
allow PC-relative jumps/calls between Code objects. This is the
reason why --interpreted-frames-native-stack was not supported on
arm and might not work on arm64 because the code range is bigger
than the max PC-relative distance for call/jump instructions.
The new builtin calls other builtins via builtins entry table which
makes the code fully relocatable and usable for any code range size.
* RelocInfo::CODE_TARGET requires a target code to be materialized
as a Code object which contradicts the Code-less builtins goal.
* The --interpreted-frames-native-stack is rarely used in the wild but
we have to pay the price of deserializing InterpreterEntryTrampoline
builtin as a Code object which consumes address space in the code
range and thus limits the number of V8 isolates that can be created
because of code range exhaustion. Now the pointer compression cage
becomes the limiting factor instead of the code range.
* We can remove complicated logic of Factory::CopyCode() and respective
support on GC side.
Bug: v8:11880, v8:8713, v8:12592
Change-Id: Ib72e28c03496c43db42f6fe46622def12e102f31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811287
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82263}
This allows arm64 to produce an extending load from ChangeInt32ToInt64(Load(x)) more frequently.
Reduces embedded code size by 0.66% for arm64.
This change gives 0.3% for Speedometer on an A55 machine.
Change-Id: Ie27a134cea3dfc8a26b87553f27ca01bf9f00f1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3803227
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: George Wort <george.wort@arm.com>
Cr-Commit-Position: refs/heads/main@{#82258}
This is a reland of commit ccde420538
Added a test case for terminating optimized bigint multiply and attached frame_state to the runtime call to provide deopt information to determine the throw location
Original change's description:
> [TurboFan] Support BigIntMultiply
>
> Bug: v8:9407
> Change-Id: Iab0a4ca8dd5d83444d1addd6043a5c8e3a8577a7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3773773
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82140}
Bug: v8:9407
Change-Id: Ia691d758265148da1de291365d41c7c1d1f98ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810391
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82232}
This is a reland of commit 491de34bcc
co-authors: Ji Qiu <qiuji@iscas.ac.cn>
Alvise De Faveri Tron <elvisilde@gmail.com>
Usman Zain <uszain@gmail.com>
Zheng Quan <vitalyankh@gmail.com>
Original change's description:
> [riscv32] Add RISCV32 backend
>
> This very large changeset adds support for RISCV32.
>
> Bug: v8:13025
> Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82053}
Bug: v8:13025
Change-Id: I220fae4b8e2679bdc111724e08817b079b373bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3807124
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82198}
v8::TracedReference is supposed to be used from objects allocated on
CppHeap. Such objects can be in construction during garbage
collection, meaning that they are unable to invoke
Trace(v8::TraceReference) as they have not been properly set up.
It is thus necessary to use conservative tracing to find
v8::TracedReference (backed by TracedNode in GlobalHandle) in
in-construction objects.
Change-Id: I5b4ac6e7805ff7ded33f63a405db65ea08d809ad
Bug: v8:13141, chromium:1322114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3806439
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82188}
With streaming compilation we delay the generation of errors until after
all bytes are received, so that potentially better error messages get
generated. With this CL we also delay the generation of errors in the
combination of lazy compilation and streaming compilation.
In particular, this CL does the following:
* It avoids the creation of a `DecodeFail` task in
`FinishAsyncCompileJobWithError`, which would create an error immediately before a potential name section arrived.
* It calls `CompilationStateImpl::SetError()` so that an error is
created once the stream finishes.
* It removes the return value of `ProcessFunctionBody` so that wire
bytes continue to be received even after a validation error.
* It adds an early exit to `ProcessFunctionBody` if
`CompilationStateImpl::failed()` is true, so that we don't continue
validation after the first detected error.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: Ie8c6be243a257ef62cbb29fea6b8e0c205060680
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3802691
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82181}
Introduce RootVisitor and related class hierarchy to just handle
roots. This avoids the awkard definitions for roots visiation in all
the cases they are not needed.
Change-Id: Ib0912e4bf543db2ecf68caead6929c68d6afdda6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782794
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82107}
This is required by the MVP spec. In the future, it might be possible
to pass values for any immutable fields.
Bug: v8:7748
Change-Id: Ie7705b48e9d6ebb87d5e1b0a2a10556302395db6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793383
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82072}
Currently, we canonicalize types for call_indirect by looking in the
current module for a signature of the same shape. This is not enough
as of wasm-gc. Instead, the canonical identifier representing a type
has to be computed via isorecursive canonicalization.
This change is implemented behind a flag for now.
Future work: Also integrate export wrappers with isorecursive
canonical types. We need to store wrappers in instance-independent
storage.
Drive-by:
- Always emit type check for call_indirect. We did not emit a check
only when typed-function-references was enabled, but not gc. This
is not something that will be possible long-term.
- Fix some wasm cctests.
Bug: v8:7748
Change-Id: I7cced187009ac148c833dff5e720a8bb9a717e68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784600
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82064}
This very large changeset adds support for RISCV32.
Bug: v8:13025
Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82053}
This is a reland of commit e895b7af73
The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
Memory64 currently does not use trap handling, so we should not allocate
a guard region (10GB total reservation).
This is implemented by adding a {WasmMemoryFlag} enum in the backing
store header, which replaces the previous {MemoryIndexType}. The flag is
not stored with the backing store, as the backing store does not care
about the index type, and we might want to share the same backing store
for memory32 and memory64 (if sizes permit this).
Instead, we (still) store the flag with the WasmMemoryObject and pass it
to the backing store methods.
R=jkummerow@chromium.org
Bug: v8:10949
Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82038}
This CL implements MemoryAllocator::LookupChunkContainingAddress, which
will be used for conservative stack scanning. The method determines
whether an address that may be an inner pointer is contained in some
allocated (normal or large) page. To achieve this, the CL introduces a
page database in the memory allocator.
Bug: v8:12851
Change-Id: I8b719a5f1b6e6b374ccf0666c91c2341c5f9856a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784986
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82004}
The RTT type can not be used directly in WebAssembly any more and is treated
as a compiler-internal type for the GC MVP.
Bug: v8:7748
Change-Id: I97cb241e6c46446149cc6ae2b1d535b93402fa76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787877
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82000}
This is a reland of commit 4e935c7ffb
fix a bug on mac for not return correct memory protection key support.
Please see details in comments.
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I5b5cc81e7c1502229ce0d2a5574ca34dc23d19d9
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng,v8_mac_arm64_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787320
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81994}
Remove the range check of formatRange, formatRangeToParts on
NumberFormat and selectRange on PluralRules
Bug: v8:10776
Change-Id: Ifede7d61db6414d5b338b22bd188406e5f7d98b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779041
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81984}
This CL refactors the mechanism for testing the implementation of inner
pointer resolution using the marking bitmap. It allows for more than one
page, where objects can be allocated. It also keeps a list of allocated
objects that are automatically tested.
Bug: v8:12851
Change-Id: I470dc1154aca1ebc3d8526872717747829f83396
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784605
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81952}
This reverts commit 4e935c7ffb.
Reason for revert: Breaking on mac arm64: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10926/overview
Original change's description:
> [pku][wasm] Refactor PKU usage in Wasm
>
> RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
> machinery.
> Wasm and V8 code space will use the same memory protection key.
>
> This is a next step towards adding PKU support for V8 code space.
>
> Bug: v8:13023
> Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81947}
Bug: v8:13023
Change-Id: I11c52ac101804ab75b1bb1d4814f083cb1083d5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780498
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81949}
RwxMemoryWriteScope becomes the bottleneck for both MAP_JIT and PKU
machinery.
Wasm and V8 code space will use the same memory protection key.
This is a next step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: I647f8c09bc41e5ef8a1d74b58a48a43e08454e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702213
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81947}
This reverts commit e895b7af73.
Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview
Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
> literal, and the old Script does not, then the old Script is updated
> to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
> function literal, and the old Script has an uncompiled
> SharedFunctionInfo, then the old SharedFunctionInfo is updated to
> point to the function_data and feedback_metadata from the new
> SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
> SharedFunctionInfo, where the old object graph contains a matching
> SharedFunctionInfo for the same function literal, then that pointer
> is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
> flushing. This is okay; the worst outcome is that the function would
> need to be compiled again later. Such a risk is already present,
> since V8 doesn't keep IsCompiledScopes for every compiled function in
> a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
> compilation. This is also okay; the merge completion logic on the
> main thread will just keep this lazily compiled data rather than
> inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
> they are no longer referenced. This is mostly okay, because any
> SharedFunctionInfo that is needed by the background merge is strongly
> referenced and therefore can't be cleared. The only problem arises if
> the top-level SharedFunctionInfo gets cleared, so the merge task must
> deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
> compilation of a parent function. This change is somewhat troublesome
> because it invalidates the background thread's work and requires a
> re-traversal on the main thread to update any pointers that should
> point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
> thread, checks whether there is a matching Script in the Isolate
> compilation cache which doesn't already have a top-level
> SharedFunctionInfo. If so, it saves that Script in a persistent
> handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
> whether the persistent handle from the first step exists (a fast
> operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
> background thread, performs step 3 of the merge described above and
> generates lists of persistent data describing how the main thread can
> complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
> steps 1 and 2 listed above, as well as a possible re-traversal of the
> graph if required due to newly created SharedFunctionInfos in the old
> Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}
Bug: v8:12808
Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81943}
Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
with which an embedder could request that V8 merge newly deserialized
script data into an existing Script from the Isolate's compilation
cache. This change implements those new functions. This functionality is
still disabled by default due to the flag
merge_background_deserialized_script_with_compilation_cache.
The goal of this new functionality is to reduce memory usage when
multiple frames load the same script with a long delay between (long
enough for the script to have been evicted from Blink's in-memory cache
and for the top-level SharedFunctionInfo to be flushed). In that case,
there are two Script objects for the same script: one which was found in
the Isolate compilation cache (the "old" script), and one which was
recently deserialized (the "new" script). The new script's object graph
is essentially standalone: it may point to internalized strings and
readonly objects such as the empty feedback metadata, but otherwise
it is unconnected to the rest of the heap. The merging logic takes any
useful data from the new script's object graph and attaches it into the
old script's object graph, so that the new Script object and any other
duplicated objects can be discarded. More specifically:
1. If the new Script has a SharedFunctionInfo for a particular function
literal, and the old Script does not, then the old Script is updated
to refer to the new SharedFunctionInfo.
2. If the new Script has a compiled SharedFunctionInfo for a particular
function literal, and the old Script has an uncompiled
SharedFunctionInfo, then the old SharedFunctionInfo is updated to
point to the function_data and feedback_metadata from the new
SharedFunctionInfo.
3. If any used object from the new object graph points to a
SharedFunctionInfo, where the old object graph contains a matching
SharedFunctionInfo for the same function literal, then that pointer
is updated to point to the old SharedFunctionInfo.
The document at [0] includes diagrams showing an example merge on a very
small script.
Steps 1 and 2 above are pretty simple, but step 3 requires walking a
possibly large set of objects, so this new API lets the embedder run
step 3 from a background thread. Steps 1 and 2 are performed later, on
the main thread.
The next important question is: in what ways can the old script's object
graph be modified during the background execution of step 3, or during
the time after step 3 but before steps 1 and 2?
A. SharedFunctionInfos can go from compiled to uncompiled due to
flushing. This is okay; the worst outcome is that the function would
need to be compiled again later. Such a risk is already present,
since V8 doesn't keep IsCompiledScopes for every compiled function in
a background-deserialized script.
B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
compilation. This is also okay; the merge completion logic on the
main thread will just keep this lazily compiled data rather than
inserting compiled data from the newly deserialized object graph.
C. SharedFunctionInfos can be cleared from the Script's weak array if
they are no longer referenced. This is mostly okay, because any
SharedFunctionInfo that is needed by the background merge is strongly
referenced and therefore can't be cleared. The only problem arises if
the top-level SharedFunctionInfo gets cleared, so the merge task must
deliberately keep a reference to that one.
D. SharedFunctionInfos can be created if they are needed due to lazy
compilation of a parent function. This change is somewhat troublesome
because it invalidates the background thread's work and requires a
re-traversal on the main thread to update any pointers that should
point to this lazily compiled SharedFunctionInfo.
At a high level, this change implements three previously unimplemented
functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
- BackgroundDeserializeTask::SourceTextAvailable, run on the main
thread, checks whether there is a matching Script in the Isolate
compilation cache which doesn't already have a top-level
SharedFunctionInfo. If so, it saves that Script in a persistent
handle.
- BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
whether the persistent handle from the first step exists (a fast
operation which can be called from any thread).
- BackgroundDeserializeTask::MergeWithExistingScript, run on a
background thread, performs step 3 of the merge described above and
generates lists of persistent data describing how the main thread can
complete the merge.
- BackgroundDeserializeTask::Finish is updated to perform the merge
steps 1 and 2 listed above, as well as a possible re-traversal of the
graph if required due to newly created SharedFunctionInfos in the old
Script.
The merge logic has nothing to do with deserialization, and indeed I
hope to reuse it for background compilation tasks as well, so it is all
contained within a new class BackgroundMergeTask (in compiler.h,cc). It
uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
the object visitation that updates pointers to SharedFunctionInfos.
[0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
Bug: v8:12808
Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#81941}
All embedders override this method now, so it can be abstract.
R=mlippautz@chromium.org
Bug: v8:12425
Change-Id: I4db5d74341c9519222592a88d247bc2aa2be03a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780538
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81910}
Avoid most of the {is_inline()} checks by having a {data_begin_} pointer
which either points at the inline storage or at the zone-allocated
memory.
This replaces a dynamic branch by a memory indirection, which is
beneficial for big (non-inline) BitVectors. For small BitVectors we will
have to see what the bots say; the hypothesis is that a memory load is
still faster than a dynamic branch.
Apart from better performance, this change allows for simpler code in
many places, including the iterator implementation.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I1e28279d1a438598e0b8403a6a4078c2cd2a4c48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776685
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81902}
Some tests and testing infrastructure had to be changed because it
relied on nominal types.
Drive-by: Support function supertypes in wasm-module-builder.js.
Bug: v8:7748
Change-Id: Ife92431d1842ff9de91e296a50421aa48f02c0de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776197
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81862}
Instead of one big test which tests multiple functions, split the unit
test into multiple smaller tests.
Also, use TestWithZone instead of TestWithIsolate, because the isolate
is never used.
R=jkummerow@chromium.org
Bug: v8:12425
Change-Id: I32148e40b5ed2b006cc647d42bdfe564ccc6d0ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3776676
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81852}
We will provide a replacement for raw pointers in future which should
only be used by backing stores. Any other callsite must go through
Trace(BasicMember<>).
Bug: v8:13089
Change-Id: Ibdae439b44ad94bd7af2532855be941c5334db99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3772328
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81833}
Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.
Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
This includes several changes:
- avoid a very-unlikely-but-theoretically-possible OOB write
- avoid a somewhat-likely memory leak
- grow the buffer less aggressively for medium-length strings
Change-Id: I877f43d7e2e7cd4778ba8c7c7525ba988301f750
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3771900
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81808}
This CL fixes a bug in the units of the reported metrics for
V8.GC.Cycle.MainThread.Full.Incremental.Mark (ms instead of us).
It also reports incremental marking/sweeping metrics (both for the
unified heap and the C++ managed heap) only when incremental
marking/sweeping were used; otherwise, no zero values are reported.
Bug: chromium:1154636
Bug: chromium:1343507
Change-Id: Ibc0103ea62fa0eeb5f7184280c8514e99a5c21a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3768502
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81803}
This adds a bunch of tracing hooks to the module decoder and uses
them to support "annotated hexdump" output for full modules in wami:
$ out/x64.release/wami my_module.wasm --full-hexdump
Change-Id: I5821d940b5ec236df9708eecd0124172d8893ffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3754741
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81791}
... in order to avoid expensive computation of cage_base for Code
objects and in order to avoid issues with wrong cage base values
computed from Code objects in external code space.
Drive-by: cage-bas'ify some accessors in JSFunction and Code.
This is a step towards Code-less embedded builtins.
Bug: v8:11880
Change-Id: I95dd8bcd4680e09c7463e1bc7d72dcbf9f2e5c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769831
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81788}
- Removed duplication and unnecessary indirection from all suites testcfgs.
- Introduced a more comprehensive context to cover both command context and other platform specific concerns.
- Propagated above context to TestLoader to allow for test counting command execution on all platforms.
- Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future.
- Consolidated progress indicators under a single processor in the pipeline.
- Consolidated result retention requirements calculation outside of pipeline chain.
- Refactored LoaderProc and got it under tests.
- Added some more tests for the standard runner.
- Extracted BuildConfig class.
Bug: v8:12785
Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81770}
- Avoid adding an Invalid type that can never be reached during
traversal;
- Expose class names as object names;
Bug: chromium:1321620
Change-Id: Ie3d9f78d97703535ecf67d56235d564ab6a9a7e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763866
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81758}
This CL refactors the implementation of inner pointer resolution, based
on the marking bitmap. MarkCompactCollector::FindBasePtrForMarking has
most of its code that processes the marking bitmap moved to a utility
function FindPreviousObjectForConservativeMarking, which iterates
backwards to find the closest previous object on the page that has been
marked.
Bug: v8:12851
Change-Id: I980ac5712d8b1df792196d77edb9526ca2e13e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758227
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81750}
As sandboxed pointers are now default-enabled when the sandbox is
enabled, it is no longer possible to deactivate the sandbox at runtime.
This CL therefore removes all the logic that was required to support a
sandbox that could be disabled at runtime, moves the initialization of
the sandbox into V8::Initialize, and deprecates V8::InitializeSandbox.
This change also makes the sandbox initialization deterministic if
FLAG_random_seed is supplied.
Bug: v8:10391
Change-Id: Ibd49f7c251b7c58c642f18a551ecc2c391740970
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762583
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81746}
As sandboxed pointers assume a constant sandbox size (they are
essentially n-bit offsets), it is no longer useful to be able to create
smaller sandboxes. This CL simplifies the sandbox initialization logic
accordingly and adds CHECKS to ensure a fixed-size sandbox is created.
Bug: v8:10391
Change-Id: I6541ab769001e60c0256d3a719f926128a0a20b0
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647684
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81720}
The operator with raw pointer allows us to avoid Member decompression,
which is more expensive than compression. It's also quite frequently
called (e.g. in HeapHashSet::find()).
The existing operator
template <...>
bool operator==(const Member<T1>&, const Member<T2>&);
was not called for
GCed* raw = ...;
member == raw;
because the compiler wouldn't deduce `T2` in `const Member<T2>` as
`GCed` when the initializer expression `raw` is of different type
(`GCed*`).
Bug: chromium:1325007
Change-Id: Ie1ee12bad28081c66f4e08a146467fd7c040bb70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757344
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81702}
This adds a new type 'none' as part of the WASM GC MVP.
The type can only be used in combination with a nullable reference, e.g.
'ref.null none'.
A 'nullref' is implicitly convertible to any nullable reference type.
Bug: v8:7748
Change-Id: Ic5ab6cc27094b3c9103ce3584452daa34633612f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755136
Auto-Submit: Matthias Liedtke <mliedtke@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81670}
If we detect out-of-order sections, we should not enter the individual
decoding functions, because they might make assumptions that are not
true in the error case.
In this case, a DCHECK was firing if we call {DecodeFunctionSection}
twice.
R=ahaas@chromium.org
Bug: chromium:1342274
Change-Id: I3d9d8c8c604aeeb92b9766f07d4b5464f4c8d72c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755112
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81662}
Page allocation in a partially-reserved sandbox is generally best-effort
once the reserved part is fully allocated, which happens in this test.
As such, there is no guarantee that this test succeeds, and it does seem
to fail in practice on some bots with memory sanitizers enabled. The
same logic is essentially tested by the
VirtualAddressSpaceTest.TestEmulatedSubspace test so simply deleting
this test should be fine.
Bug: v8:13040
Change-Id: I1469bd9d2e330a6e834bb565ce4e7f5985be28a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749180
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81578}
This is a workaround to silence gcc failures stemming from googletest
headers.
Bug: chromium:1307180
Change-Id: Ia6eb08f170f65c2fde6e4c287f9781d9df559b35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3738220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81548}
GCInfoTable is a process-global table storing Oilpan type information.
Table operations may fail in OOM scenarios which were previously just
caught in regular CHECKs. Change to use a global OOM handler that is set
up to use V8's handler.
Bug: chromium:1283199
Change-Id: Id33263ef7cd4028d60a071f5ab3b165e59ac9593
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3745368
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81540}
This adds a new --experimental-value-unavailable flag, which is disabled
for now. When enabled the debugger reports values that are optimized out
by TurboFan and values of certain variables in Temporal Dead Zones (TDZ)
as unavailable. Internally we use a special `value_unavailable` accessor
info to represent these values, and on the debugger boundary we report
these properties with `value`, `get`, or `set`.
Doc: https://goo.gle/devtools-value-unavailable
Bug: chromium:1328681
Demo: devtools-dbg-stories.netlify.app/crbug-1328681-value-unavailable
Change-Id: Idb09a4a148335a950deae60f7c07caecc48826ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3627510
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81509}
This opcode is being removed in favor of pre-declared non-defaultable
locals (details are still TBD).
Bug: v8:9495
Change-Id: I96ac053a1b5a852310c5dc0bbaeab0cbf5384663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3738743
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81496}
Most often, the {ValueType::Ref} constructor was called with a
constant nullability. To make things more convenient, this CL renames
{Ref} to {RefMaybeNull}, and introduces {Ref} and {RefNull}
constructors with fixed nullability.
Bug: v8:7748
Change-Id: I664ff184ca936cc752e152c3c67546d79aa24390
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3732936
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81494}
This makes the internal V8 name consistent with the text-format name.
Bug: v8:7748
Change-Id: I44f7ac1eb5e634b4f829e596bf1f14caeb748d54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3726291
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81491}
MinorMC maintained a separate marking state to support interleaved GCs.
Since MinorMC now assumes that interleaving is not possible, MinorMC can
use the same marking state as the full GC.
Bug: v8:12612
Change-Id: Ibeb7df2eb24e448f811b497c9d16b3b132f87ec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735163
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81468}
Fix some final gcc warnings:
* Manually roll googletest to get the fix in:
https://crrev.com/d5ad28dbe14fca51038fb8c7610f11602b98f682
* Remove some anonymous namespaces in tests because the types in those
anonymous namespaces ended up being visible in non-anonymous
classes.
* Fix a RVO breaking std::move.
* Change some known-too-short strncpys into memcpys
Bug: chromium:1307180
Change-Id: I0f64512f77655f3740fc297bbb2087e6c039f7f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735122
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81436}
Fixes the test after a perfetto roll
Change-Id: Ib861edd1f87435b6bbc5e8b7599f118c72cc0776
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3732108
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81417}
And add a test to ensure we've caught them all and won't
forget any others in the future.
Change-Id: I9bed83ada1c8991eaf08af4b34d4ccda7dc0e600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3724788
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81388}
Following change in https://github.com/WebAssembly/stringref/pull/22.
This adds two new parsing modes: a strict UTF-8 parsing mode, and a
sloppy mode that should replace invalid subsequences with U+FFFD.
Bug: v8:12868
Change-Id: I03bd8d2a3408c399ce68f7b150d7650908804113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3719919
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andy Wingo <wingo@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81337}
This reverts commit 543acf345a.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release/10365/overview
Original change's description:
> cppgc: Minor fix in cppgc efficiency calculation
>
> Efficiency calculation (freed bytes over GC duration) assumes that the
> duration of the GC is non zero. However, if the clock resolution is
> not small enough and the entire GC is very short, the timed value
> appears to be zero. This leads to NaN values showing in metrics and
> CHECKs failing. This CL fixes the issue.
>
> Bug: chromium:1338256
> Change-Id: I1dbc52072fcde3411aa38fa0c11da25afd107ca8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714356
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81329}
Bug: chromium:1338256
Change-Id: Ie9a23651494fc28a11bb59485a9812ee1a7cff48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721697
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#81331}
Efficiency calculation (freed bytes over GC duration) assumes that the
duration of the GC is non zero. However, if the clock resolution is
not small enough and the entire GC is very short, the timed value
appears to be zero. This leads to NaN values showing in metrics and
CHECKs failing. This CL fixes the issue.
Bug: chromium:1338256
Change-Id: I1dbc52072fcde3411aa38fa0c11da25afd107ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714356
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81329}
- Check that internalized strings always have a computed hash value.
- Check that ThinStrings never have a forwarding index.
- Add a simple test of various property access with
--always-use-string-forwarding-table to make the CF aware of the flag.
Change-Id: Ie047c9f635d5e0ed999208ec3379ef09c395b3f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717988
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81303}
This CL introduces a compile flag v8_enable_inner_pointer_resolution_osb
behind which lies the experimental implementation of the object start
bitmap. It disassociates the object start bitmap from the compile flag
v8_enable_conservative_stack_scanning. At the moment the former flag is
a prerequisite for the latter, as conservative stack scanning requires
some mechanism for inner pointer resolution and the object start bitmap
provides one such mechanism.
Bug: v8:12851
Change-Id: I24c6b389453fbaefc79ae50c34c5ec7a1bf23347
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3717322
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81295}
Initial implementation for concurrent shared arrays. Current implementation exposes a `SharedArray` constructor, but its syntax might
change in the future.
Shared arrays can be shared across Isolates, have a fixed size, have no
prototype, have no constructor, and can only store primitives, shared structs and other shared arrays. With this CL shared structs are also allowed to store shared arrays.
The Backing storage for the SharedArrays is a `FixedArrayBase`. This CL introdces a new ElementKind: `SHARED_ARRAY_ELEMENTS`. The new kind should match the overall functionality of the `PACKED_SEALED_ELEMENTS` kind, but having it as standalone kind allows for easier branching in CSA and turbofan code.
Bug: v8:12547
Change-Id: I054a04624d4cf1f37bc26ae4b92b6fe33408538a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585353
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81285}
Creates a feature (flag): transition from Done -> Wait
schedules a timer after 30s instead of 8s.
In local benchmark, this reduces by 50% cpu time spent doing
incremental marking and sweeping.
Bug: chromium:1330940
Change-Id: Iff9121243b88d0ed87d0b921e285ece52a83eaa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3696168
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81283}
This merges the separate opcode name definitions from wasm-opcodes-inl.h
into the main opcode-defining macros in wasm-opcodes.h. This is simpler
(avoids a bunch of fairly complex macros) and easier to update when we
add new opcodes in the future.
The tests become obsolete because they would simply repeat the implementation.
Change-Id: Ib6421da5670079e7725659c1f4008251f8ff7aed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714244
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81280}
This is a reland of commit 5b9401dde4
Now also skip tests that require large amounts of virtual address space
if tsan is enabled as tsan may cause V8 to create a smaller sandbox
which is then unable to allocate the required amount of memory.
Original change's description:
> [sandbox] Also enable the sandbox outside of Chromium builds
>
> Drive-by: include the right header in sandboxed-pointer-inl.h and fix
> missing sandbox initialization in generate-bytecode-expectations.cc.
>
> Bug: v8:10391
> Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81216}
Bug: v8:10391
Change-Id: I141080fdf61a77ef48b22e353e3cfbc1ff816e5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716474
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81277}
The spec uses "v128" (not "s128") as the vector type name.
Some conversion instructions have more specific names that we used to
print, e.g. "i32x4.trunc_sat_f32x4_s" instead of "...convert...".
Bug: v8:8460
Change-Id: I4e06f452de6ce8b06670a8c5e53142c36d5e6010
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704497
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81274}
This is a reland of commit 538f2bc9ab
Changes compared to original: None. We think the problem that caused
the revert (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/9377/overview) is unrelated.
Original change's description:
> [wasm-gc][cleanup] Remove wasm signature from CallDescriptor
>
> This field is no longer used, as the functionality it supported has been
> subsumed by wasm-gc typed-based optimizations.
>
> Bug: v8:7748
> Change-Id: I970514bb29e5f91bb5610cafde60ec3dbcfb07aa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705376
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81244}
Bug: v8:7748
Change-Id: I8eacff98d265751fae55f244d40c0df94e35e6fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714231
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81248}
This field is no longer used, as the functionality it supported has been
subsumed by wasm-gc typed-based optimizations.
Bug: v8:7748
Change-Id: I970514bb29e5f91bb5610cafde60ec3dbcfb07aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705376
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81244}
Remove finalization step of incremental marking. The step was
historically used to process embedder/weak work on the main thread
before invoking the atomic pause. Remove the infrastructure as the
step is not needed anymore and actually required a safepoint.
Change-Id: I208767bbac3d9a06a0b3c67aa9779f8a5fa07328
Bug: v8:12775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702801
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81234}
Due to shared GCs it's easy to accidentally deadlock V8 by forgetting to
park a thread before blocking.
This CL does the following:
- Adds ParkingConditionVariable and ParkingSemaphore, which hide
the Wait[For] methods in favor of ParkedWait[For], which parks the
thread before blocking the thread.
- Migrate to the Parking* variants in JS shared memory tests.
Bug: v8:11708
Change-Id: I6d1b2b26a05e7df0a69a1614c03308f538a8782f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3708017
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81225}
Drive-by: include the right header in sandboxed-pointer-inl.h and fix
missing sandbox initialization in generate-bytecode-expectations.cc.
Bug: v8:10391
Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81216}
This reverts commit 8325f86df3.
Reason for revert: Speculative revert for chromium:1336850.
Original change's description:
> [heap] Sweep code pages on the background thread
>
> We already make code pages writable & executable for concurrent
> Sparkplug. We can use the same mechanism for sweeping of code pages on
> the background thread, instead of scheduling incremental tasks on the
> main thread. This allows us to remove almost all special
> handling for code pages in the sweeper and allows us to off-load more
> work from the main thread.
>
> Bug: v8:12967
> Change-Id: Idb8e9f8e2eadbec26a386f2de683a80087f671f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695557
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81139}
Bug: v8:12967, chromium:1336850
Change-Id: I1fb775892c2679984221efa7ceb682800c88cb2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707274
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81213}
The CL fixes PMF regressions that happend after increasing
the AgeTable size.
Bug: chromium:1336529
Change-Id: If1f099b43bfcb3a8c7dd4a1c229fcb08735eb744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707098
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81180}
This CL explicitly disables the --freeze-flags-after-init flag for cases
where we modify flags after initialization. This is only tests, fuzzers,
and special options to d8, thus not security relevant.
These should be the last blockers for enabling the flag globally.
R=cbruni@chromium.org
Bug: v8:12887
Change-Id: I1d8a03dcc20e524d30c967f6fe15f6401de77612
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706619
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81179}
CreateJob() is similar to PostJob() but doesn't schedule anything
until Join() or Notify*() is called.
This allows
- CreateJob().Join() without too many worker.
- Early 'empty' CreateJob() for initialization
without causing spurious calls to GetMaxConcurrency()
Bug: chromium:1287665
Change-Id: I8fd8b139392ad30218f0cf8f580b2d76f1078777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668842
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81166}
"Function:" and "LazyCompile:" are confusing by now and use up too
much space.# Enter a description of the change.
This also changes the function names visible when using linux-perf
Change-Id: Ib2d4b7df39068c27b5b06db578fc550d2973ebb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693705
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81161}
The names we returned in WasmOpcodes::OpcodeName(...) for Atomics opcodes
did not match the spec. This patch fixes that.
This matters in particular when we want to provide disassembly of
modules.
Bug: v8:6532
Change-Id: Ia8791feee617b75d598ad373bafba7da5687f523
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3704496
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81142}
We already make code pages writable & executable for concurrent
Sparkplug. We can use the same mechanism for sweeping of code pages on
the background thread, instead of scheduling incremental tasks on the
main thread. This allows us to remove almost all special
handling for code pages in the sweeper and allows us to off-load more
work from the main thread.
Bug: v8:12967
Change-Id: Idb8e9f8e2eadbec26a386f2de683a80087f671f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695557
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81139}
We don't need to reset the entire age table, but merely the pages that
are known to contain young objects. This must improve memory use with
generational GC enabled.
The CL is a prerequisite for another CL that'll increase the size of
the age-table.
Bug: chromium:1029379
Change-Id: Ibb5b607af20380c3936b7396b3d9767f6f17c44b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695268
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81106}
Adds Module::GetStalledTopLevelAwaitMessage() API which searches for
modules that have no pending async dependencies but have not yet
resolved. An embedder may call this API when they are about to exit
to check if TLA evaluation has stalled and provide a better error
message.
Change-Id: I3b88802f70cc84c973551f13d73ef3e3d06f4027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341765
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81080}
Add a missing check to reject illegal sections.
The test is added in three forms, to give fuzzers more food: A fuzzer
regression test for the streaming fuzzer, a unit test for the streaming
decoder, and an mjsunit test for streaming compilation.
Drive-by: Remove a redundant line in the synchronous decoder (this is
already handled by the following statement.
R=ahaas@chromium.org
Bug: chromium:1335023
Change-Id: Ic8c3b301f1b58981c7d68eafcffc89531ed2c64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3698549
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81071}
Currently, PageAllocator assumes that FreePages(start, size) will always
be called on the same region that was passed to AllocatePages(start,
size). This assumption is made in:
1) leak-sanitizer (LsanPageAllocator) that checks it explicitly,
2) on Windows, FreePages() calls VirtualFree() with zero-size and
MEM_RELEASE, which causes the entire reservation to be freed.
The CL temporarily fixes the bot failures just by holding the unneeded
half and adds a TODO to return the unneded part back to the OS.
Bug: chromium:1325007
Change-Id: I2bd878876d43d693cf2138020f410ffe1615b4e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695363
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81059}
Compaction currently considers only backing store pointers as slots and
those are uncompressed. The CL fixes the tests to use raw pointers
instead of Members.
Bug: chromium:1325007
Change-Id: I2ddfffeeab396552bb7cf31b2bd8502ebc2921fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695590
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81056}
After flags are frozen, this will not work any more. It's also not
required, as flags cannot be accessed after teardown anyway.
This CL changes that to only release the memory of dynamically allocated
string flags, which is something we still need to do after
write-protecting the flags anyway.
R=tebbi@chromium.org
Bug: v8:12887
Change-Id: Iff0e3845cbd91fb59878b2ed36a44d6df00572f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695379
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81030}
The CL does the following:
1) Globalizes CagedHeap for all HeapBases;
2) Adds the global variable representing the cage base;
3) Changes all write-barriers to use this global variable for value/slot
checks;
4) Removes no longer needed functionality introduced in previous CLs.
Bug: v8:12231
Change-Id: I281a7b0bf67e349c988486fc2d43ec6d703fd292
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688050
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81027}
We will not be able to modify flags after initializing V8 (soon).
The {SingleThreadedDefaultPlatformTest} was resetting flags during
teardown for no reason, as we do not support running multiple tests in a
row anyway. Thus remove that use of {SaveFlags} and just set the
--single-threaded flag before initializing V8.
R=ahaas@chromium.org
Bug: v8:12887
Change-Id: Ia89d442cf4b2fe2e12e258da5c0c9f1f871ded12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695378
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81024}
Add a simple, linear-time scheduler to check whether two nodes can be
scheduled to a same basic block without actually building basic blocks.
Bug: v8:12716
Change-Id: I20506f28a9126f881b7e4748f54b12551967ba76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388910
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#81015}
The test should now be self-skipping without extra work
Bug: v8:12547
Change-Id: I0adf5d8745e19b17d2644587e416eb16063b210d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3694455
Reviewed-by: Milad Farazmand <mfarazma@redhat.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81013}
Earlier, we had to introduce some temporary workarounds in Turbofan to
enable optimizations for common wasm-gc patterns. These are now not
required, since these optimizations are applied in WasmTyper and WasmGCOperatorReducer.
Bug: v8:7748
Change-Id: I3a7bc4bd2a8023a438ee4620934ff3fcb8bcfc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693999
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81011}
Not all V8 build configs support JS shared memory features. Trying to
create a new shared Isolate on such a config DCHECKs at runtime. Make
the shared Isolate test fixture conditionally initialize the shared
Isolate. Users must explicitly check for support.
Bug: v8:12547
Change-Id: I3df1ce7eb5ae9a3c136f88ea8f44c650cc0408ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687565
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80961}
When a 8x16 shuffle matches a packed byte to dword zero extension,
1. input1 is S128Zero after canonicalization,
2. the indices {0,4,8,16} are consecutive value in the range [0-15] and
other indices are in the range [16-31],
the shuffle can be matched to packed byte to dword zero extend. These
shuffles are commonly used in image processing.
Change-Id: I14d1e35401dbc5ecd91f67c46ea9762628835d01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3547667
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Cr-Commit-Position: refs/heads/main@{#80953}
The CL splits the Oilpan giga-cage in two 2GB reservations: one for
normal pages and the other for large ones. The split enables fast
page-header lookup (assuming most objects reside on normal pages), which
is needed for:
1) the young generation project, where the remembered set will move to
pages;
2) the shared-cage project, to find HeapBase* from page-headers.
Bug: v8:12231, chromium:1029379
Change-Id: I4ae9e8a75a307ed0dff9a2ec4f1247b80e17ebd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688519
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80950}
Applying the set of unittest changes from
https://crrev.com/c/3678208 to BE.
Change-Id: I02d0f2f388720e3acc35660042d5c2c76fa589e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687474
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80942}
