The fast path of Array#toSpliced currently does not correctly initialize
the elements range in the copy's FixedArray elements that will hold the
inserted items. A GC can occur between the initial allocation of the
elements before the inserted items are copied into it, which will fail
heap verification.
This CL also refactors CSA's FillFixedArrayWithSmiZero method to support
only zeroing a portion of a FixedArray instead of the entire thing.
Bug: v8:13035
Change-Id: I1bdb77d3b27f682620b45caa5a9c10ea0072a6ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3750321
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81665}
Add a CreateFunctionContext implementation (which calls the same builtin
used by Sparkplug), and fix our deopt checkpoints to include the context
as a pseudo-register, so that Push/PopContext work with deopts.
Bug: v8:7700
Change-Id: Ia3efd105683f6922181b9f4c7db0bac6a3a5fcec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757683
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81664}
The wasm instance got pushed three times in the lazy-compile builtin:
1) as part of the parameters;
2) as a parameter for the runtime function;
3) to load the jump table address after the runtime function;
The third push can be avoided by loading the jump table address after
all parameters get loaded from the stack again.
R=clemensb@chromium.org
Bug: v8:13049, v8:12926
Change-Id: I6117cfbbabc6250bf40732b6921c0e629fd85fa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755138
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81663}
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}
With the flag --always-use-forwarding-table we could end up turning a
String into a ThinString that had a forwarding index set.
This could happen when a String with a forwarding index is externalized.
Bug: chromium:1337469
Change-Id: Iea05586f61e2b78d83d04d5d2e94c4dca2892c1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735164
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81660}
... in order to prepare for smoother rollout via the finch flag.
Bug: v8:12054, chromium:1343515
Change-Id: I24f51b73daa35c8de6967e8eb088dd3bee95fc4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755120
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81659}
With pointer compression enabled the compiler may not inline some Member
functions on some platforms, because Member stores and loads become
slightly more expensive. Inlining is however important with pointer
compression - it allows to further optimize the code by eliminating
the global load.
Bug: chromium:1325007
Change-Id: Ia37d223e78853a8218e0b2732a3f08aa58929000
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3756141
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81648}
This CL is part of an effort to enable concurrent marking in MinorMC.
For this purpose we plan to reuse the IncrementalMarking class which
already implements a part of the concurrent marking code for MajorMC.
IncrementalMarking internally uses the MarkingWorklists class.
This CL adapts the stop-the-world marking implementation of
MinorMC to use the MarkingWorklists class.
Bug: v8:13012
Change-Id: I3c4eb33142f2630e89aa3771b6065b9f82dc0847
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3747862
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Leon Bettscheider <bettscheider@google.com>
Cr-Commit-Position: refs/heads/main@{#81646}
Bytecode generation already emits a manual runtime call for
CreateFunctionContext in the case where the slot count exceeds the
maximum, so we don't need to check for this case in Sparkplug.
Change-Id: I228bc710c5093f7c752dc7bda7912e3af1547371
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755118
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81645}
Previously SnapshotCreator demanded a blob to be created before
it can be destructed in debug build, this patch removes the
DCHECK so that the embedder can choose not to create the blob
when e.g. the snapshot building isn't successful due to errors.
Change-Id: I72939be1e0d79b257b9761f48a72e45325a1f6d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716682
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81644}
There seem to be some issues with sandboxed external references in the
serializer which cause the --stress-snapshot mode to fail. This CL
changes the serializer to serialize external pointers that are
unsandboxed (currently all of them) as "regular" external references,
not "sandboxed" ones. This should fix the issues on the bots.
Bug: v8:10391
Change-Id: I2f889e1d0aa9c5958d4f4337e114423b650c1bb2
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/+/3755148
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81643}
Change StoreField to StoreTaggedField, which, similar to the move of
LoadField to LoadTaggedField, operates on an offset and not a full Smi
handler. Then, add support for stores to a property array by emitting a
LoadTaggedField of the property array.
As a drive-by, fix support for const fields and HeapObject fields with
a class field type.
Bug: v8:7700
Change-Id: Iff1fec35b82d3999ff273b069e9935166f43b98f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3752802
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81640}
Suspender.{returnPromiseOnSuspend,suspendOnReturnedPromise}
are not tied to a specific suspender anymore, so move them to
WebAssembly.{returnPRomiseOnSuspend,suspendOnReturnedPromise}.
With this change, the suspender property is not needed anymore on the
function data. Convert it to a boolean flag that just indicates whether
a function uses the JS Promise Integration API.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I1b6d8e3190ebf5049dbc7eedee448999cf077509
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3748660
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81639}
The comment was right but the actual condition wasn't. We should check
whether the value is _not_ loadable.
Bug: v8:7700
Change-Id: I1c721a56da5860c73c8179406abb1d3a8b9d08f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3755111
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81638}
This CL does the following:
- It enables (i.e. allocates and initializes) the per-Isolate
ExternalPointerTable when the sandbox is enabled.
- It refactors the list of external pointer tags to mark them as
"sandboxed" or "unsandboxed". An unsandboxed external pointer has a
null tag.
- It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just
enable sandboxing for all available tags.
- It modifies all low-level external pointer accessors to perform the
ExternalPointerLookup only if the tag is non-zero and otherwise treat
the slot as containing a raw pointer.
This now allows rolling out external pointer sandboxing incrementally
(separately for each external pointer type), which will in turn allow
for more precise performance measurements of the impact of the sandbox.
Note: when an external pointer tag is now marked as sandboxed (and
V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are
still 64-bits in size. This simplifies the implementation as we would
otherwise need to deal with variably-sized external pointer slots. Local
benchmarking suggests that the benefits from 32-bit external pointer
slots are insignificant on typical benchmarks, so this should be ok.
Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to
make it more clear what it refers to (the on-heap storage size). Also
delete CodeStubAssembler::InitializeExternalPointerField as it is not
currently used and the implementation is fairly inefficient.
Bug: v8:10391
Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab
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/+/3736447
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81636}
Run Maglev on the Linux64 bots -- eventually we'll want to move it to
the extra variant, but for now the flag is x64-only.
Bug: v8:7700, v8:12727
Change-Id: I8b8329720ac96ab1655aef9e210a52092f81cc91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3752979
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81635}
Previously, the d8 prompt was printed without flushing stdout. This
relies on the platform's libc to flush stdout when reading from stdin.
This behavior is not portable and breaks the prompt on some platforms.
Change-Id: Ieddf7ec5a6eab15796e69742bb4c9546ceb54c37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3752006
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81634}
This CL is the first step towards the 'static API':
https://github.com/WebAssembly/js-promise-integration/pull/1/files
The limitation of the previous API is that the stack-switching wrappers
are tied to a particular suspender. Since a suspender cannot be
re-entered until the corresponding computation has completed, this
prevents creating multiple concurrent instances of the same export.
Multiple APIs have been proposed and are still under discussion to
solve that, but the core idea is the same: the suspender should become a
runtime argument of the export and the import. This CL implements that.
For now, the suspender is still explicit everywhere: it is created in JS
and passed to the export, and forwarded to the JS import. Eventually,
the suspender may be completely hidden from JS: it would be materialized
by the export wrapper, and "swallowed" by the import wrapper, as
proposed in the PR above.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: Ic425a3fd920c7ad03874c636cd835d31c0e04994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3748655
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81633}
SynchronizePageAccess is used to synchronize between page initialization
and reads from that page. It was not used for main thread reads because
it was assumed that all pages are initialized on the main thread. With
concurrent allocations, pages may be concurrently initialized, thus
requiring a fence for main threads reads as well.
Bug: v8:13041
Change-Id: I93e5162243ef5458579f239b131094d7171e8615
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3752804
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81630}
