Introduce v8::ArrayBufferBase as a common base class for ArrayBuffer
and SharedArrayBuffer, moving shared methods (ByteLength, MaxByteLength,
IsShared, IsDetachable, WasDetached, IsImmutable, CopyArrayBufferBytes,
GetBackingStore, IsResizableByUserJavaScript, Data) and constants to the
base class, and unifying TypedArray::New and DataView::New to accept
Local<ArrayBufferBase>.
Add GetBuffer() returning Local<ArrayBufferBase> on ArrayBufferView and
WasmMemoryObject, deprecate Buffer() forwarding via UnsafeAs, and remove
the final exception in TypeCheckLocal.
TAG=agy
R=leszeks@chromium.org
Bug: 419454582
Change-Id: If597b100487c65e931498a9bd4a56aa161df4b7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8586076
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110818}
Replace all internal occurrences of v8::MemorySpan and v8::to_array
with std::span and std::to_array, respectively, and mark them as "soon
to be deprecated".
Bug: 361372981
Change-Id: I5702b41b4e0dbbeba4c4a110c6988764fdd18da3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7867713
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107949}
SandboxContains is useful for asserts for embedders
who want to be sure their ArrayBuffer backings are
allocated in the correct sandbox (for those using
multiple IsolateGroups and therefore multiple sandboxes).
For embedders providing a custom ArrayBufferAllocator they
need access to the virtual address space so they can get
in-sandbox pages for their allocator. There was already
an API method GetSandboxAddressSpace(), but this uses the
current group/sandbox, which is inconvenient when setting
up multiple isolate groups/sandboxes.
Change-Id: I94f1fcb80b5ca76df038928decc06887993682a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6575561
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#100420}
In multi-sandbox mode it is impossible to directly specify which
sandbox to use for the default array buffer allocator.
This CL adds a new version NewDefaultAllocator(isolate group)
that will solve the issue.
Bug: 342905186
Change-Id: Ic4cb9b7f9dbbf6325ec1b71a1ddb492c77ae2a51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6239499
Commit-Queue: Dmitry Bezhetskov <dima00782@gmail.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98753}
The embedder can intercept and deny large array buffer allocations through the ArrayBuffer Allocator. If allocations above a certain size are always going to be rejected it makes sense to detect this early and throw exceptions rather than cause a fatal OOM in the VM. With this change the embedder can set an upper limit that will be handled more cleanly.
Change-Id: I3ab54afe7e203d5b82ce9022ae129702fad61c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6098133
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98290}
v8::ArrayBuffer::Allocator::Reallocate and v8::BackingStore::Reallocate
have been deprecated for 7 months.
Fixed: 331326406
Change-Id: I454d22bf82e924462f19cc00f913be033d596013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6180598
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98166}
V8 provides APIs to access the data and length of an ArrayBufferView
individually. However, by having to do two API calls one either has to
create a HandleScope to store a reference to the ArrayBufferView after a
type check, or one has to do the type check twice. In a node.js micro
benchmark this causes a 100% regression compared to the new API that is
introduced with this CL, where data and size can be acquired with a
single API call.
Bug: 356158110
Change-Id: I0d58bdcff36992be824c9cdf2b2165a30ab335e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5915615
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96701}
This allows the embedder to try to allocate a large ArrayBuffer
and handle the error more elegantly if it fails.
This removes a TODO, suggesting such an API might exist.
Thanks to Brett Hoerner.
Change-Id: Iacec17b63cf312a66abecc154d04e6d69f1e7cbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5913522
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96495}
Allow configuring the number of embedder fields ArrayBuffer and
ArrayBufferView objects have. Blink doesn't need these extra fields
anymore and we can save some space and speed up GC processing. Retain
ability for embedders to use the fields though via gn arg.
Bug: 346350847
Change-Id: I48e56de316ae932a43012c0736fd36ea6e9c80ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5621990
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94377}
Most ArrayBuffer that go through the standard bindings code checks for
IsResizableByUserJavaScript. The existing implementation first acquired
the BackingStore from the ArrayBuffer, and then load
IsResizabelByUserJavaScript from there. However, acquiring the
BackingStore requires creating a new std::shared_ptr, which showed up in
profiles of benchmarks. The new API introduces a fast path for
IsResizableByUserJavaScript that avoids the shared_ptr.
Bug: chromium:41492790
Change-Id: Id1dc27ca778962690c31fa4552e80f61b50a3b78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5273190
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92229}
I originally thought MaxByteLength would only be needed for
v8::ArrayBuffer and v8::SharedArrayBuffer, but it is also needed on
v8::BackingStore.
In particular, blink uses Mojo to serialize ArrayBuffers' contents via
v8::BackingStore when doing cross-process postMessage.
Bug: chromium:1396361, v8:11111
Change-Id: I86d44829175ad760fb43294d386483a16044fc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090708
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84767}
Adds v8::[Shared]ArrayBuffer::MaxByteLength and
v8::BackingStore::IsResizableByUserJavaScript.
This is needed for embedders who need to check if a buffer is resizable
by user JS, like blink, to check for the [AllowResizable] WebIDL
extended attribute.
Bug: v8:11111
Change-Id: Ie7e03979ef3884123df8a3eeb5c3516c4a6967c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4082276
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84715}
V8's C++ API does not give a way to tell whether an ArrayBuffer has
been detached from the `v8::ArrayBuffer` class. In fact, as far as can
be told from the C++ API without running JS code, detached
ArrayBuffers behave the same as zero-sized ArrayBuffers and there is
no way to observe the difference. However, this difference can be
observed in JS because constructing a TypedArray from a detached
ArrayBuffer will throw.
This change adds a `WasDetached` method to the `v8::ArrayBuffer` class
to give embedders access to this information without having to run JS
code.
Bug: v8:13159
Change-Id: I2bb1e380cee1cecd31f6d48ec3d9f28c03a8a673
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810345
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83963}
Raw data access is already possible via GetBackingStore()->GetData().
This API exposes a more efficient way for accessing
JSArrayBuffer::backing_store (which, despite the confusing name, is no
the BackingStore but its raw data pointer).
Bug: v8:10343
Change-Id: I695cea91e2c3de75ce6c86bac6e413ce6617958b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764341
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81745}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
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/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
This is a reland of d1b27019d3
Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
This reverts commit d1b27019d3.
Reason for revert: Broke vtune build, tsan build and possibly others
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.
Every include of v8.h from inside v8 has been changed to a more
fine-grained include.
Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.
None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.
v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.
Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
Clemens Backes
criskell
Nikolaos Papaspyrou
Ben Noordhuis
Olivier Flückiger
Erik Corry
Dmitry Bezhetskov
Shu-yu Guo
Andreas Haas
Leszek Swirski
Michael Lippautz
Andreu Botella
Marja Hölttä
Samuel Groß
Dan Elphick