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}
If enabled, a signal handler is installed which intercepts memory access
violations (e.g. SIGSEGV) and checks whether they occurred inside the
sandbox address space, in which case the process is terminated cleanly
as this does not represent a (security) issue with the sandbox. However,
if the access violation occurred outside the sandbox, the access
violation is forwarded to the original signal handler.
The filter can be enabled in d8 by specifying
--enable-sandbox-crash-filter.
Bug: v8:12878
Change-Id: If9d76267e90ee79ee81ab793d7774afed6226b7c
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/+/3688408
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@{#80999}
This is a reland of commit ea9a1f1cbe
Changes since revert:
- Make the state field uintptr-aligned since arm64 faults on
atomic accesses to non-naturally aligned addresses.
Original change's description:
> [shared-struct] Add Atomics.Mutex
>
> This CL adds a moving GC-safe, JS-exposed mutex behind the
> --harmony-struct flag. It uses a ParkingLot-inspired algorithm and
> each mutex manages its own waiter queue.
>
> For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
>
> Bug: v8:12547
> Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80789}
Bug: v8:12547
Change-Id: I776cbf6ea860dcc6cb0ac51694a9b584b53d255c
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3673354
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@{#80875}
Replace all usages of UPDATE_WEAK_WRITE_BARRIER with
UPDATE_WRITE_BARRIER. The barrier wasn't hot, so the additional branch
for the marking barrier shouldn't be a problem.
Performing the marking barrier could in theory cause more floating
garbage. However in this case the write barrier is only run once
directly after e.g. allocating a Code or NativeContext object. Since
UPDATE_WEAK_WRITE_BARRIER only skips the marking barrier, we should only
observe different behavior when marking is on. But since we already
have black allocation for objects in old space, we will not cause
additional floating garbage.
In case of performance regression, we should also be able to replace
those usages with SKIP_WRITE_BARRIER, since NativeContext and Code
objects are never allocated in the young generation, so running the
generational barrier shouldn't be necessary. It's just hard to DCHECK
that SKIP_WRITE_BARRIER is valid here.
Bug: v8:11708
Change-Id: I25d760a46d1d7ec973cc589f51ddf80ca3b5419d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663080
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80839}
This CL adds a moving GC-safe, JS-exposed mutex behind the
--harmony-struct flag. It uses a ParkingLot-inspired algorithm and
each mutex manages its own waiter queue.
For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
Bug: v8:12547
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80789}
When enabled, this API exposes a new global 'Sandbox' object which
contains a number of functions and objects that in effect emulate
typical memory corruption primitives constructed by exploits. In
particular, the 'MemoryView' constructor can construct ArrayBuffers
instances that can corrupt arbitrary memory inside the sandbox. Further,
the getAddressOf(obj) and getSizeInBytesOf(obj) functions can be used
respectively to obtain the address (relative to the base of the sandbox)
and size of any HeapObject that can be accessed from JavaScript.
This API is useful for testing the sandbox, for example to
facilitate developing PoC sandbox escapes or writing regression tests.
In the future, it may also be used by custom V8 sandbox fuzzers.
Bug: v8:12878
Change-Id: I4e420b2ff28bd834b0693f1546942e51c71bfdda
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/+/3650718
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80659}
Now that we require C++17 support, we can just use the standard
static_assert without message, instead of our STATIC_ASSERT macro.
R=leszeks@chromium.org
Bug: v8:12425
Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80524}
This CL adds two experimental JS builtins to convert between
i16 Wasm GC and JS strings. This is a non-standard experimental
feature only available with the flag --wasm-gc-js-interop.
WebAssembly.experimentalConvertArrayToString(array, start, count)
Convert the `count`-many WTF-16 code units starting at index `start`
into a JS string. Throws a TypeError if `array` is not an i16 array,
or if `start` and `count` are not numbers or not in range.
WebAssembly.experimentalConvertStringToArray(string, sampleArray)
Convert `string` to an i16 array. The `sampleArray` parameter needs
to be an arbitrary i16 array, which is only used to extract the rtt.
Throws a TypeError if `string` is not a string or `sampleArray` is not
an i16 array.
Change-Id: I7ac2f6bd89b8f638427f61da1bb01ccba90d735b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642301
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80505}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
Make the file names consistent on "shadow-realm" (i.e. singular, with a
dash).
Bug: v8:11989
Change-Id: Id0a6f417fd9b53b9f7ddf9677da7396fa2481af6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606392
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80164}
Invoking a JSBoundFunction is slightly slower than a normal
JSFunction (since we don't have to first jump to the
target_function).
The closure steps in SourceTextModule ExecuteAsyncModule is
controlled by the engine so it is better to create dedicated
context slots for the captured values.
Change-Id: I8163fc4b302d6d22906e578164470c9e28e768e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3584601
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80155}
As per https://tc39.es/ecma262/#sec-hostimportmoduledynamically defined,
referencingScriptOrModule in HostImportModuleDynamically can be a Script
Record, a Module Record, or null.
So to https://tc39.es/proposal-shadowrealm/#sec-shadowrealmimportvalue,
the HostImportModuleDynamicallyCallback is been invoked with a `null`
resource_name. This may not be considered a breaking change as the
parameter resource_name is defined as Local<Value>.
Updates d8's DoHostImportModuleDynamically to handle null resource_name,
and resolve the dynamically imported specifier relative to the executing
script's origin. In this way, we have to set ModuleEmbedderData.origin
even if the JavaScript source to be evaluated is Script. Also, a
ModuleEmbedderData is created for each ShadowRealm to separate their
module maps from the initiator context's.
Bug: v8:11989
Change-Id: If70fb140657da4f2dd92eedfcc4515211602aa46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522883
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80118}
CacheInitialJSArrayMaps was called in the middle of
JSFunction::SetPrototype even though this only happens during
bootstrapping given that Array.prototype os non-configurable and
non-writable.
Changes:
- Rename CacheInitialArrayMaps to InitializeJSArrayMaps
- Add more explicit checks in InitializeJSArrayMaps to link back
to the Context indices for better code searching
Change-Id: Iad6d20e3d67d715bfd6429037c75ac35ab7f399f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571889
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79973}
A worker might be terminated while creating a new Realm. While this was
handled mostly correctly already, a DCHECK was places slightly too
early, which is fixed by this CL.
Also, we avoid printing an error message if we fail to install an
extension due to isolate termination. As this is externally triggered,
it's not really an error condition.
R=jkummerow@chromium.org
Bug: chromium:1313475
Change-Id: I67b7fd27002d9b9a33439378d8336fefb2a2371a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571811
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79825}
... with zero cost.
Bug: v8:9357
Change-Id: I66985c3fd3e7b4efa354eb564c641562cf55ab49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518909
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79632}
HeapObjectIterator creates a SafepointScope which requires the heap to
allow garbage collection. This collides with the outer
DisallowGarbageCollection scope. HeapObjectIterator already ensures
there is no allocation during its lifetime, so there is no need to
create an outer DisallowGarbageCollection scope.
Code::source_position_table requires their kind not equals to
CodeKind::BASELINE.
This also exposes the statistics extension through flag
--expose-statistics.
Bug: v8:12657
Change-Id: I1bf11cf499285a742dd99ec8c228ebc36152b597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3496552
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#79425}
Clean up two flags which control features shipped in m99
harmony_intl_locale_info
harmony_intl_enumeration
Bug: v8:10743, v8:11638
Change-Id: I856afaceb0972052d1bcc70b162e8f9ee9071dd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3508169
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79397}
Embedder fields are located between JSObject header and inobject fields
and there must be no gaps.
This CL adds respective check to Map verification and fixes existing
issues.
Bug: v8:10391
Change-Id: If55652095588f8704c9a375fb86be1599816aa86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3482436
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79227}
This is a reland of 1025bf26e3
Changes since revert:
- TSAN issue fixed by https://crrev.com/c/3475084
- Skip the shared-struct-workers test until shared GC deadlock is fixed,
being tracked in v8:12645
Original change's description:
> [shared-struct] Prototype JS shared structs
>
> Unlike the Stage 1 proposal, for simplicity the prototype does not add
> any new syntax, instead opting for exposing a SharedStructType
> constructor which takes an array of field names. This type constructor
> returns constructors for shared structs.
>
> Shared structs can be shared across Isolates, are fixed layout, have no
> prototype, have no .constructor, and can only store primitives and
> other shared structs.
>
> The initial prototype does not have TurboFan support.
>
> Bug: v8:12547
> Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79156}
Bug: v8:12547
Change-Id: Ic1f5cf9fa9791ae2d5d5dc7c110614ca10b5d98e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475078
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79215}
This reverts commit 1025bf26e3.
Reason for revert: https://crbug.com/v8/12645
Original change's description:
> [shared-struct] Prototype JS shared structs
>
> Unlike the Stage 1 proposal, for simplicity the prototype does not add
> any new syntax, instead opting for exposing a SharedStructType
> constructor which takes an array of field names. This type constructor
> returns constructors for shared structs.
>
> Shared structs can be shared across Isolates, are fixed layout, have no
> prototype, have no .constructor, and can only store primitives and
> other shared structs.
>
> The initial prototype does not have TurboFan support.
>
> Bug: v8:12547
> Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79156}
Bug: v8:12547
Change-Id: I44f2b8bb7487b4d39ba1282585e0b2282501230f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474676
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79170}
Unlike the Stage 1 proposal, for simplicity the prototype does not add
any new syntax, instead opting for exposing a SharedStructType
constructor which takes an array of field names. This type constructor
returns constructors for shared structs.
Shared structs can be shared across Isolates, are fixed layout, have no
prototype, have no .constructor, and can only store primitives and
other shared structs.
The initial prototype does not have TurboFan support.
Bug: v8:12547
Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79156}
Originally, the accessors wont be copied into global object from
deserialized global. And the accessors in serialized global object
will be lost. Fix to copy accessors in deserialized global
into global object when recreating new global object using passed
global proxy template.
Tests credited to xiangyangemail@gmail.comhttps://chromium-review.googlesource.com/c/v8/v8/+/3405405
Bug: v8:12564
Change-Id: Iefb3a6dbfa5445b227d87c26eb423cf1b924dbb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3459937
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79087}
Not all environments (like ShadowRealm) would expect console
APIs to present in their globals. Moving console API to
context's extras binding to allow them to be still
snapshotted to not slow down the bootstrap.
The console API is not removed from the global in this CL,
but it is planned to be removed in the later release.
Bug: v8:11989
Change-Id: Ieca09e0bafdf8943e8fff8fee97fc21c2326320f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364786
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#78998}
