This is a reland of 3cb4039cd1
Changes since revert:
- Fix FLAG_stress_scavenge interaction with shared Isolate
- Use the shared Isolate's global handles to keep shared values
alive in transit during a postMessage
Original change's description:
> [string] Support shared strings in Value{Serializer,Deserializer}
>
> When FLAG_shared_string_table is true, postMessaging strings will share
> instead of copy.
>
> Note that not all operations on shared strings are supported, and shared
> strings may be slower than non-shared strings for some operations.
>
> Bug: v8:12007
> Change-Id: I3462128e15410d2568868143571571b3025722c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78614}
Bug: v8:12007
Change-Id: I5d9b99b2dac6f26d5ef046d7aec94f1a1d219419
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3389533
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78761}
The hello world sample needs to initialize V8's default platform in case
it is not built as stand-alone example.
Bug: v8:12427
Change-Id: I78b68fbed2c2a25b0ff03675beb94dfc5b9b4135
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412088
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78756}
When sandboxed external pointers are enabled, external pointers now only
require 32 bits of storage space in a HeapObject. This CL does not shrink
the size of EmbedderDataSlots, which will happen in a follow-up CL.
Bug: v8:10391
Change-Id: I3cf8b68c3b985cf806a45183717f50462a88c281
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/+/3359629
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78754}
So far this flag was process-global, so if one isolate used v8::Locker
all isolates were forced to use v8::Locker. With the shared isolate
now being a thing that routinely gets migrated between different
threads, all users of the shared isolate would be forced to use
v8::Locker. So we now store that flag on the isolate such that using
v8::Locker for the shared isolate does not affect other isolates.
Deprecate v8::Locker::WasEverUsed() at the same time.
Bug: v8:11708
Change-Id: I60531f084cc1b1b113620c46f5bed20511f52c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401595
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78712}
The external pointer table is now managed by the GC, which marks entries
that are alive during major GC, then sweeps the table afterwards to free
all dead entries and build a free list from them. For now, only major GCs
are supported, Scavenger GCs do not interact with the external pointer table.
In more detail, garbage collection of the external pointer table works
as follows:
1. The external pointer table now reserves a large region of virtual
address space for its backing buffer and is then never reallocated,
only grown in place until the maximum size is reached.
2. When the GC's marking visitor marks a HeapObject with an external
pointer as alive, it also marks the corresponding external pointer
table entry as alive. This can happen on a background thread.
3. For that, it uses the MSB of each entry in the table to indicate
whether the entry has been marked or not. This works because the MSB
is always cleared during the AND-based type check performed when
accessing an external pointer.
4. After marking, the external pointer table is swept while the mutator
is stopped. This builds an inline, singly-linked freelist of all
newly-dead and previously-free entries.
5. When allocating an entry from the table, the first entry on the
freelist is used. If the freelist is empty, the table grows,
populating the freelist with the new entries.
6. Every newly-allocated entry is marked as alive, and every store to an
existing entry also automatically marks that entry as alive (by also
setting the MSB). This simplifies the design of the table GC with
regards to concurrency (See ExternalPointerTable::Mark).
Bug: v8:10391
Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14
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/+/3359625
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78708}
Also:
- Refactor the ValueSerializer tests using raw data, so that we test all
valid versions for each test (not only one hard-coded one)
- Mark some tests as backwards compatibility tests, to make it less
likely that somebody updates them not realizing they are backwards
compatibility tests.
Bug: v8:11111, v8:12532
Change-Id: I670849de07742c8d442249ef4f013781e4ee9255
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386802
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78681}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. To help in this case, this CL introduces a new
CDP method "Runtime#getExceptionDetails" that behaves exactly as
advertised: It provides a populated "ExceptionDetails" structure
from a JS Error object.
R=bmeurer@chromium.org
Doc: https://bit.ly/runtime-get-exception-details
Bug: chromium:1278650
Change-Id: I084be10c1d852d3b7cac8d88e7f820e867be4722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337258
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78676}
This CL introduces a dedicated API to retrieve the current (w.r.t. the
JS stack) script name or sourceURL. Currently, API clients will
collect multiple stack traces in increasing sizes to accomplish the
same goal. The new method walks the JS stack in the same way as the
stack trace collection mechanic but doesn't create/allocate stack info
or callsite objects along the way.
R=bmeurer@chromium.org, yangguo@chromium.org
Doc: https://bit.ly/v8-current-script-name
Bug: chromium:1286677
Change-Id: Id53e4f04bf17349d34f3d581bc712b1f4aa055db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3382818
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78645}
When FLAG_shared_string_table is true, postMessaging strings will share
instead of copy.
Note that not all operations on shared strings are supported, and shared
strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I3462128e15410d2568868143571571b3025722c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78614}
Use grep to check for obviously unneeded includes. e.g. headers that
include <vector> but does not contain "std::vector".
Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78613}
The total wall time for GC reported to Blink is explicitly included in
UMA events. For the C++ managed heap, it is equal to the sum of the four
phases (mark, sweep, compact, weak). For the JS heap, it will be greater
than or equal to that sum in general.
Bug: chromium:1154636
Change-Id: Id710702b8e9d8db5c8d1eb4917deb6b760a77306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386596
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@{#78611}
In the C++20 a following paper was implemented [1]. This
paper makes code below illformed. The high level idea is
that as soon as class gets non default constructor - all
default initializations are not added implicitly.
class A {
public:
A(const A&) = delete;
};
int main() {
A a{};
return 0;
}
So if V8 embedder is building its code with C++20 it can
not initialize v8::CppHeapCreateParams struct and as a
result can not create a CppHeap.
One of the possible mitigations (3.3) from the paper is
to add non copyable field into class. Luckily there
is std::vector<std::unique_ptr>> in this class already.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf
Change-Id: I8a2dc35784d7646b5f73a5e178716e9bf2ffe601
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3348007
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78504}
New text is moved over from BlinkGCDesign.md
Bug: chromium:1283934
Change-Id: I10a84c91a642e96c494d6e523d6d89059afaa1ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366658
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78498}
Previously, guard regions were created by allocating pages with
PROT_NONE and relying on an allocation hint. This could fail however,
for example on Fuchsia (where it would allocate a VMO to back the guard
region) and possibly on Windows (where a placeholder mapping was
replaced by a "real" mapping).
Introducing an explicit VirtualAddressSpace::AllocateGuardRegion routine
now makes this operation more efficient and effectively guarantees that
it cannot fail if used correctly: in a regular subspace, there is no
need to allocate anything when creating guard regions since the address
space reservation backing the subspace is guaranteed to be inaccessible
when no pages are allocated in it.
Bug: chromium:1218005
Change-Id: I6945f17616b6b8dad47241af96d4cb1f660e8858
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/+/3366237
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78480}
The v8-debug.h and its implementations in api.cc are effectively owned
by the DevTools team.
Bug: none
Change-Id: I0eacb901bad771fca9aff19ded6bde0c34753174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361835
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78453}
This introduces a new `GetLocation()` method for `v8::StackFrame`s,
which returns both line and column number at the same time (using the
existing `v8::Location` class). Since `v8::StackFrame` instances store
only the source position (per https://bit.ly/v8-stack-frame), we
currently need to look up the source position in the Script's line table
twice, once when we request the line number, and another time when we
request the column number.
With `GetLocation()` we perform only a single lookup in the Script's
line table and return both line and column number at the same time. This
cuts roughly 8% of the average execution time from the `standalone.js`
benchmark mentioned in crbug.com/1280519.
Bug: chromium:1280519, chromium:1278650, chromium:1069425
Bug: chromium:1077657, chromium:1283162
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Change-Id: Ia3a0502990b6230363112a358b59875283399404
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359628
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78452}
Report young generation GC statistics to the Recorder API.
These will be used by Blink to populate UMA histograms.
Existing UMA reporting in V8 remains as is for now and will be removed
in a followup.
With this CL, minor mark-compaction statistics are reported as part
of V8.GC.Cycle.*.Young. Also V8.GCScavengeReason is migrated to
V8.GC.Cycle.Reason.Young.
This CL goes together with:
https://chromium-review.googlesource.com/c/chromium/src/+/3320388
Bug: chromium:1154636
Change-Id: Ia1030c80d4bc75ac6e176ed60f838929ddb9b20f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320430
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@{#78416}
This is the first step towards moving away from sending `url` with every
call frame when emitting the `Debugger.paused` event.
Bug: chromium:1270316, chromium:1271078
Change-Id: I2f57f21e15bf908ffb53f5c7b5862d3efa329c86
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344946
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78392}
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}
The execute_us is now tied to the --slow-histograms flag.
This currently enabled on a small population as a persistent finch study
which should give us enough coverage for now.
Drive-by-fixes:
- Rename counter: execute_precise() to execute()
- Avoid Leave/Enter overhead in NestedTimedHistogramScope if the
histogram is not enabled
- Only stop timers in debug mode for NestedTimedHistogramScope
Bug: chromium:1275056
Change-Id: Id6a492bdd68edb5194cb191c7083829a9f90283f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320431
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78318}
This is a reland of 2d087f237e
The changes are :
* Fix redundant reinterpret_cast in test file for MSVC failure
https://crbug.com/v8/12476
* Fix flaky test
https://crbug.com/v8/12475
If a sample is captured during a GC, no embedder context is obtained
defaulting to EMPTY. This is the expected behavior, made it in clear
in implementation and in test.
* Synchronized the embedder context filter behavior with existing
native context filter.
Original change's description:
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871
Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78281}
Checks whether a Persistent is used from the creation thread on slow
path allocations. In practice, these currently happen every 256
Persistent allocations. This is a best effort check that may help to
flush out issues that are missed with DCHECK builds.
Bug: chromium:1276570
Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78276}
This reverts commit 2d087f237e.
Reason for revert:
- Causing MSVC build failures: https://crbug.com/v8/12476
- Causing flaky failures: https://crbug.com/v8/12475
Original change's description:
> [profiler] Surface VM & Embedder State
>
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871, v8:12475, v8:12476
Change-Id: I02670b1ed3bb863033208369227642a7419fce00
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315444
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78256}
Rename StringShape::full_representation_tag to
StringShape::representation_and_encoding_tag, since the full
representation tag now includes the shared bit.
There are no users of the new method in this CL; this is split out to
make subsequent shared string CLs smaller.
Bug: v8:12007
Change-Id: Ic4ac0241fd9846241e85b4a094dfee6d201ba42b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313428
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78253}
Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
EmbedderState:
* An EmbedderState is defined as a value uint8_t and a v8::context used
for filtering.
* EmbedderStates are stack allocated by the embedder, construction and
destruction set/unset the state to the isolate thread local top.
* A v8::context is used to filter states that are added to a CpuProfile,
if the CpuProfile do not have a ContextFilter set or if contexts do not
match, state defaults to Empty.
* v8:StateTag is already propagated all the way to a Sample, simply add
an API to surface it.
VMState:
Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
Bug: chromium:1263871
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78250}
This CL reverts two diagnosing CLs that introduced same-thread CHECKS,
recovering all introduced performance regressions.
We will try to add less performance-sensitive checks again in a follow
up.
This reverts commit 0c2bbfd5bb.
This reverts commit 6643c05940.
Bug: chromium:1253650, chromium:1243257, chromium:1274201
Change-Id: I96c41c39c4f58b062574fa11c4a2d76ad030bcf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315437
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78245}
This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.
The new interface is not yet stable and may change at any time without
deprecating the old version first.
Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
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/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
This CL turns references to ArrayBuffer backing stores from
JSArrayBuffers, JSTypedArrays, and JSDataViews into CagedPointers
when those are enabled.
CagedPointers cannot generally represent nullptr, as NULL usually lies
outside the cage. As such, nullptr backing stores are replaced with a
special empty backing store value, which, in the current implementation,
points to the end of the cage, right in front of the trailing guard
regions. Due to this, it is no longer correct to compare a backing store
pointer against nullptr.
Bug: chromium:1218005
Change-Id: I4a6c7a82aabb4debcb6bb2babe4035ba2da8e79f
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/+/3244419
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78218}
Some performance sensitive paths in V8 (compilation/json parsing) or
paths with high allocation/freeing throughput can suffer from not being
able to reuse recently freed allocations. These paths can also
significantly increase the working set and cause large number of page
faults. For such paths (at least as an initial measure) we are planning
to disable allocation quarantining.
The CL provides a way for the embedder to hook in *Scan functions that
disable/enable quarantining. It also disables *Scan for json parsing and
compilation jobs.
Bug: chromium:1249550
Change-Id: I0274f66010435f3d4d091fe70fabcd20f46dc0d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306389
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78178}
- V8::Deprecate ShutdownPlatform in favor of V8::DisposePlatform
- Rename i::V8::TearDown to i::V8::Dispose
- Clean up i::V8::Initialize
- Remove needless V8::Initialize() calls in cctests
- Remove CcTest::DisableAutomaticDispose()
- Add checks to Isolate::Allocate and Isolate::Dispose that there is
and active platform
Change-Id: Iac84f9ade9d1781e9e8b8c88ea8fe74013f51c4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306482
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78162}
It's deprecated in C++17 and not needed (it was needed for static const,
but not for constexpr). It's needed in C++14, but can trigger
deprecation errors in C++17, so include it conditionally on __cplusplus.
Bug: chromium:1274247
Change-Id: I92524f377bb92ac2aa008f15830920786a1c1432
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308795
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78157}
These methods were declared as inlined functions but the implementation
were moved to api.cc.
Change-Id: I49071aca9c94e52930c362e85206dbda402ab29b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308375
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78148}
This is a reland of 4997ce58dd
Original change's description:
> cppgc: Add targeted CHECK for diagnosing Peristent issue
>
> The added CHECK aims at finding problems where Peristent is used off
> the owning thread.
>
> Bug: chromium:1253650, chromium:1243257
> Change-Id: Ia0cbc6005aba38c0d98197ed18c3b40dd2dc33fd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306972
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78137}
Bug: chromium:1253650, chromium:1243257
Change-Id: I9ef72d3f649c1a4504417c4cd7728e5000675405
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306487
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78146}
The added CHECK aims at finding problems where Peristent is used off
the owning thread.
Bug: chromium:1253650, chromium:1243257
Change-Id: Ia0cbc6005aba38c0d98197ed18c3b40dd2dc33fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306972
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78137}
This CL removes registration of CppHeap as a remote tracer, and
revises LocalEmbedderHeapTracer as a switching point between CppHeap
and a remote tracer. Currently it is assumed that CppHeap and a remote
tracer are mutually exclusive and only one can be used at any given
time.
Bug: v8:12407
Change-Id: I53513d181ab63f56a88f05c3b76b47ac4dffe86f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289167
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78132}
This allows the embedder to determine whether some function has been
called from a destructor.
See discussion in
https://crrev.com/c/3302810
Bug: chromium:1273928
Change-Id: Icb5d98eff777574488a7d6de5e693c502c2fb53e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303793
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78113}
This is a reland of d7c3f1cd8a. It fixes
a build failure on native arm64.
Original change's description:
> Reland "[fastcall] Enable float support on arm64 simulator"
>
> This is a reland of b9ddcbc86f
>
> The original CL was reverted due to an MSAN issue, that is fixed by
> moving the signature mapping onto the Isolate (instead of having
> per-thread storage, which got invalid on multithreaded compilation).
>
> This CL also contains fixes for the Bazel config and for a data race
> when obtaining the PerIsolateSimulatorData.
>
> Original change's description:
> > [fastcall] Enable float support on arm64 simulator
> >
> > This CL adds support for handling calls to C functions with arbitrary
> > signatures on the arm64 simulator. It adds infrastructure for
> > encoding the signature data from CallDescriptor and FunctionInfo
> > classes into a compact representation, stored in the simulator and
> > called EncodedCSignature.
> >
> > Design doc:
> > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
> >
> > This CL is a follow up on the native support added in
> > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> > and is partially based on the previous attempt:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
> >
> > Bug: chromium:1052746
> > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> > Commit-Queue: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77744}
>
> Bug: chromium:1052746, chromium:1267854
> Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78018}
Bug: chromium:1052746, chromium:1267854
Change-Id: Ib495573569a6c930b8f9e5f1fe7ff46eb57a0aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295461
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78063}
This is an unused overload, which doesn't add any value to keep around.
Bug: none
Change-Id: I6e004e28f6ec8d4c8de87a1e86d331a624694659
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297896
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78052}
This CL adds `can_use_compiled_module` parameter to
WasmStreaming::Finish() that is used by Chromium
https://chromium-review.googlesource.com/c/chromium/src/+/3282643
to invalidate compiled module bytes after SetCompiledModuleBytes().
Bug: chromium:1260939
Change-Id: Iebf0e8615c27c8622721777c664b06a53fb9ee91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297548
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78044}
The macro may be defined but the value to it may not be assigned. The
compiler can complain about (reproduced when compiling chromium on
Windows).
Bug: chromium:1249550
Change-Id: I684997ccda7122f56c01391e7a1339fadf6589e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3297888
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78040}
This reverts commit d7c3f1cd8a.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Android%20Arm64%20-%20debug%20builder/22043/overview
Original change's description:
> Reland "[fastcall] Enable float support on arm64 simulator"
>
> This is a reland of b9ddcbc86f
>
> The original CL was reverted due to an MSAN issue, that is fixed by
> moving the signature mapping onto the Isolate (instead of having
> per-thread storage, which got invalid on multithreaded compilation).
>
> This CL also contains fixes for the Bazel config and for a data race
> when obtaining the PerIsolateSimulatorData.
>
> Original change's description:
> > [fastcall] Enable float support on arm64 simulator
> >
> > This CL adds support for handling calls to C functions with arbitrary
> > signatures on the arm64 simulator. It adds infrastructure for
> > encoding the signature data from CallDescriptor and FunctionInfo
> > classes into a compact representation, stored in the simulator and
> > called EncodedCSignature.
> >
> > Design doc:
> > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
> >
> > This CL is a follow up on the native support added in
> > https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> > and is partially based on the previous attempt:
> > https://chromium-review.googlesource.com/c/v8/v8/+/2343072
> >
> > Bug: chromium:1052746
> > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> > Commit-Queue: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77744}
>
> Bug: chromium:1052746, chromium:1267854
> Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78018}
Bug: chromium:1052746, chromium:1267854
Change-Id: Ia8f10d085d13990b331f306957f95ecf3e003cfd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295453
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78019}
This is a reland of b9ddcbc86f
The original CL was reverted due to an MSAN issue, that is fixed by
moving the signature mapping onto the Isolate (instead of having
per-thread storage, which got invalid on multithreaded compilation).
This CL also contains fixes for the Bazel config and for a data race
when obtaining the PerIsolateSimulatorData.
Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}
Bug: chromium:1052746, chromium:1267854
Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78018}
Once CppHeap moves away from EmbedderHeapTracer, it can no longer be
returned by Isolate::GetEmbedderHeapTracer. Blink currently uses
GetEmbedderHeapTracer to trigger GCs. This CL introduces a variant of
Isolate::RequestGarbageCollectionForTesting to replace that.
Bug: v8:12407
Change-Id: I099989f55291a0daab7d2051072dedddef58dd40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293413
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78015}
This is a partial revert of https://crrev.com/c/2033171 to bring back
WasmModuleObject::Compile, that compiles Wasm bytes into a Wasm module.
Also adding a simple test to make sure the compile works.
There are some users, e.g. Cloudflare, Halide, see bug for more details.
Bug: v8:10461
Change-Id: I199abea108311025decad793d2232a08bba05d38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3292088
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78003}
The is_shared bit bumps the number of reserved bits for Strings'
InstanceType from 6 to 7. This has the side effect of shuffling the
InstanceType enum values.
There are no users of this bit yet. This is steps 1-2 from the following
design doc [1], in preparation for sharing internalized and
in-place-internalizable strings.
[1] https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edit?usp=sharing
Bug: v8:12007
Change-Id: Idf11a6035305f0375b4f824ffd32a64f6b5b043b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266017
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77831}
In the future we will allow arbitrary objects as host-defined options.
To prepare the embedders for the upcoming changes we migrate the API
to use v8::Data where possible.
Internally we still use i::FixedArray with primitive values until the
migration to context-stored host-defined options is completed.
Note: This CL also introduces a temporary cast and inheritance
between Data and PrimitiveArray which will be removed again.
Bug: chromium:1244145
Change-Id: I852d0d827708d32b6f3a6d03457234a006e2fd77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264285
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77795}
This reverts commit b9ddcbc86f.
Reason for revert: Hits unreachable on MSAN, see https://bugs.chromium.org/p/chromium/issues/detail?id=1267854
Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}
Bug: chromium:1052746, chromium:1267854, chromium:1267841
Change-Id: If3d5aaab6b5f4309ce90add614d674aaa86b43c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268910
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77788}
Explicit write barriers for internal fields are deprecated as they are
automatically emitted by V8.
Depends on:
https://crrev.com/c/3263924
Bug: v8:12356
Change-Id: I171ba5b42a6570ce52e2e2ea1b7c1029d5a8a3a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263888
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77772}
This CL adds an Allocator to SmallVector to control how dynamic
storage is managed. The default value uses the plain old C++
std::allocator<T>, i.e. acts like malloc/free.
For use with zone memory, one can pass a ZoneAllocator as follows:
// Allocates in zone memory.
base::SmallVector<int, kInitialSize, ZoneAllocator<int>>
xs(ZoneAllocator<int>(zone));
Note: this is a follow-up to crrev.com/c/3240823.
Drive-by: hide the internal `reset` function. It doesn't free the
dynamic backing store; that's a surprise and should not be exposed to
external use.
Change-Id: I1f92f184924541e2269493fb52c30f2fdec032be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257711
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77755}
The new callback does no longer use ScriptOrModule but rather gets the
host-defined options and the referrer name as separate arguments.
This brings us one step closer to deprecate ScriptOrModule and putting
the host-defined options in the script context.
- Add v8::Data::IsFixedArray and cast helpers
- Deprecate HostImportModuleDynamicallyWithImportAssertionsCallback soon
- Add Script::Run entry point that explicitly takes host-defined
options (unused yet)
Bug: chromium:1244145
Change-Id: I08bc92cfb3b79d840e766fb71b8d91d301f4399c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263893
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77733}
The goal of the PR is to add to telemetry a metric estimating the space
occupied by the codemap retained by a CpuProfiler and its underlying
CodeObserver.
This change is motivated by the addition of kEagerLogger to CpuProfiler
which when enabled let a CpuProfiler build a CodeMap without an active
session. This metric will help us understand better the space consumed
by a profiler in that scenario and will also help detect memory leaks.
Bug: chromium:1241491
Change-Id: Iadb1ed52b4c1ac70bc554942b4fa795cdf1212f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3224567
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Cr-Commit-Position: refs/heads/main@{#77703}
Currently, in the following struct
struct LayoutObject : GarbageCollected<>, MixinA, MixinB {};
the subobject that corresponds to the first base GarbageCollected<>
always takes up some space (one word). The empty-base-optimization
doesn't happen because the second base (MixinA) has the same subobject
as the first base (GarbageCollected), which is the most parent class
GarbageCollectedBase. The compiler can't "merge" them because it must
guarantee that distinct objects of the same type have distinct
addresses.
The attribute [[no_unique_address]] doesn't work for base classes,
unfortunately (but is a good idea for a Standard proposal). As a
solution, the CL simply removes GarbageCollectedBase.
Bug: chromium:1260797
Change-Id: I415b10a5fbcebce3d6ee97b8870ea9ae90f383a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259654
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77693}
- Fix definition and declaration of noexcept methods not matching
- Disable test using deprecated APIs. Only having clang coverage is
okay here.
Change-Id: I412d0b0087b2858fb72b0365b94b82ebc13462de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256693
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77665}
Trait requires methods taking `const void*` as they are passed along
as regular TraceCallback.
Bug: v8:12165
Change-Id: Ic5cfb8dba070e5a2c0087069086c925c5318fb8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253354
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77623}
The trait is expected to return a nullptr for the base address. This
is required for ephemeron tracing to trigger eagerly tracing a value.
This will be required when Blink uses a type alias to TracedReference.
Bug: v8:12165
Change-Id: Ibe142eaff41616c9de6ae0db9878f8489a5e4142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253345
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77619}
A CagedPointer is guaranteed to point into the Virtual Memory Cage and
will for example be used for ArrayBuffer backing stores when the heap
sandbox is enabled. In the current implementation, CagedPointers are
stored as offsets from the cage base, shifted to the left. Because the
cage base address is usually available in a register, accessing a
CagedPointer is very efficient, requiring only an additional shift and
add operation.
Bug: chromium:1218005
Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f
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/+/3123417
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77614}
TracedReferenceBase use (traced) global handles to implement the
referencs. Provide a write barrier in the corresponding handle
methods. Doing so
- avoids bugs by having embedders taking care of write barrier
management.
- speeds up the barrier as it is better integrated in the handle
methods.
Drive-by: We don't need write barriers on initializating stores.
Bug: v8:12165
Change-Id: Ie49cc3783aeed576fd46c957c473c61362fefbf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247039
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77593}
- Introduce v8::ScriptCompiler::CompileFunction
- Deprecate v8::ScriptCompiler::CompileFunctionInContext
- Add v8::Function::GetUnboundScript
- Add v8::Script::GetResourceName
The ScriptOrModule out-parameter is only used by NodeJS since we don't
allow arbitrary objects has host-defined options and they need a way to
keep the options alive.
This CL deprecates the out-parameter and adds helper methods to
address the most common use-cases.
The final fix still requires more fundamental changes on how host-defined
options are handled.
Bug: chromium:1244145
Change-Id: Id29de53521ad626c41391b8300146ee37a1b8a51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245117
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77564}
Using v8::Object::GetCreationContext().ToLocalChecked() causes needless
binary size regression on android due to the additional call after
migrating to the non-deprecated GetCreationContext API.
Bug: chromium:1166077, v8:11451, v8:11165
Change-Id: Ic5e2aada4d47392c5d61b419c19b5bcdbf869f0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244411
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77563}
A test was overflowing on the progress counter when using int as type.
This CL is fixing the progress counter to use uint32_t, and re-enables
the test.
Why uint32_t instead of size_t?
In the referenced bug, the progress_counter_ (but not the
progress_total_) triggered an overflow; and since these two counters
should be relatively similar (the total count is an estimate, and can
be less than the actual progress count), we do not expect the
count to increase much more than we can already encode with int.
Bug: chromium:1246860
Change-Id: I9769884ef60d352b3787c2223e528ddf33b0b23e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245116
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77551}
Some fields didn't have default values, which made it impossible to
check whether or not all fields are initialized.
Bug: chromium:1056170
Change-Id: I8c6f89e64661420460bfc351473a47a623ef6399
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3243462
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77535}
v8_enable_v8_checks has very little coverage outside of V8 itself.
Move pointer verification checks behind DEBUG so that they fire in
regular debug or dcheck_always_on builds.
Change-Id: Ib2803240dd996f4223e403d20e927aff2955afbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3242006
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77534}
Persistent node slots are dynamically allocated and their allocation
may fail. Delegate to the proper OOM handler in this case.
Bug: chromium:1243257
Change-Id: I985f5b0c940f7ac4996f3f3243123a07119005b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3240786
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77523}
GCC on x86 wants alignof(std::max_align_t) == 16 which is not
supported by Oilpan. Stricter checks in
MakeGarbageCollectedTraitBase::Allocate() cover problems per type.
Bug: v8:12295
Change-Id: Icdd6517a2828280ed19279ca45004e26c99505a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229372
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77432}
Besides the virtual memory cage, the DecommitPages API is also now
required for Cppgc with crrev/c/3211583.
A working implementation of this API is availabe in src/base/platform
for all supported platforms and is used by the DefaultPlatform.
Bug: chromium:1218005
Change-Id: I29765993ed54bb52de71998ae8c6295637ee4072
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211584
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77396}
This function tries to determine the number of virtual address bits
available on the current CPU and with that the maximum size of the
userspace address space. On x64, it can be implemented through CPUID.
The result of this function is now used in two ways: first, it limits
the maximum size of the virtual memory cage, currently to a quarter of
the address space. Second, it influences the placement of fake cages,
which are attempted to be placed into the lower half of the address
space so that they are followed by large amounts of (hopefully) unused
but addressable virtual memory in which pages can be allocated.
Bug: chromium:1218005
Change-Id: I0edc5d241d899f16dbc47492fa1534b6aaa4aa13
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220348
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77393}
V8 can fall back to creating a virtual memory cage that does not have
the desired security properties but at least allows V8 to run when
caging is enabled. This API allows the embedder to determine which kind
of cage is being used, for example for metrics collection.
Bug: chromium:1218005
Change-Id: I6988d0a4fce8aeb1361b30fce8c9c2f68f3b92f9
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220343
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77392}
This is a reland of 1ea76c1397
Disabled the failing test on Fuchsia until its PageAllocator
respects allocation hints.
Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> 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/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}
Bug: chromium:1218005
Change-Id: I2ed95d121db164679c38085115e8fa92690c057e
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/+/3220151
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77378}
This reverts commit 1ea76c1397.
Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976?
Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> 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/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}
Bug: chromium:1218005
Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77368}
On operating systems where reserving virtual address space is expensive,
notably Windows pre 8.1, it is not possible to create a proper virtual
memory cage. In order to still be able to reference caged objects
through offsets from the cage base on these systems, this CL introduces
a fake cage mechanism. When the fake cage is used, most of the virtual
memory for the cage is not actually reserved. Instead, the cage's page
allocator simply relies on hints to the OS to obtain pages inside the
cage. This does, however, not provide the same security benefits as a
real cage as unrelated allocations might end up inside the cage.
Bug: chromium:1218005
Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
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/+/3217200
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77367}
assume_aligned allows the caller may assume alignment of the allocation
methods.
Bug: v8:12295
Change-Id: I0c946dd668ae9c0c1d83da7278ad8d87bab96717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218984
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77366}
Adds support for double-word aligned, i.e., 8 bytes on 32-bit
platforms and 16 bytes on 64-bit platforms, objects in Oilpan.
Changes:
- Adds generic alignment APIs and overrides.
- Internal logic to support double-word aligned allocations on LABs.
- Adjusts natural alignment of large objects to follow double-word.
- Adds a new static_assert() that suggests users file a bug if higher
alignment is required.
- Statically checks that no allocations with non-default alignment
target custom spaces that support compaction.
Bug: v8:12295
Change-Id: I05766ce2349055d5d78b68919be00e7ee91d5505
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218150
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77348}
Used to be needed for streaming but we don't use it anymore.
Change-Id: I0947155bec38a6b329452e42204f07170a72c155
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217195
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77339}
This CL reorders the initialization scheme for shared and client
Isolates such that clients attach to the shared Isolate before
setting up the Heap. This is to support sharing the string table.
Bug: v8:12007
Change-Id: Icb0e40cc5ed84d516c8073a70d0f769f517044c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039264
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77307}
WebAssembly dynamic tiering should be tested with an origin trial. For
the origin trial the feature flag value has to be loaded from blink.
This CL stores the value of the --wasm-dynamic-tiering flag in the
compilation state, from where it gets passed forward to all uses of the
flag. The flag value gets loaded from blink when a new NativeModule is
created.
R=clemensb@chromium.org
Bug: v8:12281
Change-Id: Ia26355a665b7dfcdb47144863c1bec296774abb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3204963
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77256}
IsActive is misleading as the current implementation forces to use
v8::Locker for all Isolate access once any Locker has been used in
the same process.
Bug: chromium:1240851
Change-Id: Ieb2cfa352313b6f2cbec1bafdbc94a3fc718f3d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190093
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77243}
There is a demand of access to %Array.prototype% in Blink in
order to implement Web IDL observable array type.
Bug: chromium:1201744
Change-Id: I31ca5cd746f3a2eab8bd291741408a1dea17c122
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194025
Auto-Submit: Yuki Shiino <yukishiino@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77200}
This CL adds a getStorageIfAligned method to obtaining a typed pointer
to the underlying TypedArray data, if the pointer to it is properly
aligned.
Bug: chromium:1052746
Change-Id: Ie8cb3438135b0da060e2b42ec71bba0e72ae4f5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3195875
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77184}
Off heap members are "safe" to reference dead objects since they are not
connected to the object graph and do not ressurect the object.
This is needed becuase Members are used as temporary on stack variables
in Blink, e.g. when querying if a HeapHashMap contains a key.
Bug: v8:11749
Change-Id: I7ab2559d00c366480a3efbc0512bb1d1f63b64e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182223
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77063}
The CL provides a way for the embedder to hook in a special malloc-like
allocator that will be used for zone allocations.
An alternative approach would be to use weak functions with branches,
checking whether the functions were available at link-time. Those
branches could be optimized away with LTOs, so they would essentially
be free. However, the weak function approach is not portable (e.g.
there is no easy way to emulate it with msvc). The approach can be
revisited if indirect call turns out to be expensive (e.g. on hardware
with weak branch target predictors).
The CL is a prerequisite for running PCScan in the renderer process.
Bug: chromium:1249550
Change-Id: I221dcb2486c13e8e6e6761839ba391978319bde4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172760
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77012}
This bailout applies only when young generation is disabled.
Otherwise, getting the caged heap is required and the global load
bailout becomes redundant.
Bug: chromium:1056170, chromium:1239030
Change-Id: I826b355f4356a5c20812d9c8bf6ebc7ea0997b8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173685
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77006}
This CL exposes the size of the virtual memory cage to the embedder
through V8::GetVirtualMemoryCageSizeInBytes(). This will for example be
useful to collect metrics about the cage reservation, such as how
frequently it fails, in the future. While collecting these metrics
directly in V8 would also be possible, it would require access to an
Isolate, which is not yet available when the cage is initialized. As
such, it is easier to enable the embedder to collect these metrics.
Bug: chromium:1218005
Change-Id: Ie9c9ca7d1cd158ec024be6ab2418f50083b06d6e
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172762
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76969}
Use <iosfwd> where possible, in particular in public headers
(include/v8-*.h).
R=cbruni@chromium.org
Bug: v8:11879
Change-Id: I9d6095e6385229763d667f5064a794d67952b2b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160517
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76956}
At least for the initial rollout, we will gracefully handle cage
reservation failures by shrinking the size of the cage until the
reservation succeeds or the size drops below the mimimum cage size. This
will allow collecting statistics on how often cage reservation failures
occur in practice for different cage sizes, which will in turn influence
the decision on how to handle them in the future.
Bug: chromium:1218005
Change-Id: Ica58951ba51ac01bc2c387b34dfc8d9051ed4d75
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168347
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76948}
.. for more efficient access to builtins from generated code.
Root-relative accesses tend to be faster and produce more compact
code when the root-relative offset is small. IsolateData contains
a few large tables (roots, external references, builtins), resulting
in very large offsets in general.
This CL starts by splitting the builtin table into tiers: tier 0
is a minimal set of perf-critical builtins that should be cheap to
access. The offset to tier 0 builtins is guaranteed to be small.
The full builtin table also remains in IsolateData for occasions in
which we need to lookup builtins by index.
In future work, we can also split external references and roots into
tiers.
On x64, this reduces deopt exit sizes from 7 to 4 bytes and from 12
to 9 bytes (dynamic map checks / EagerWithResume deopts).
Bug: v8:12203,v8:8661
Change-Id: I5a9ed22b0e00682aca1abcf15892ae1458dbdd70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162142
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76947}
Instead of explicitely splitting the cage into two separate regions, we
now just create a single BoundedPageAllocator to manage the entire
address range of the cage, then allocate the first 4GB for the pointer
compression cage.
Bug: chromium:1218005
Change-Id: I02c53ca8b6dda9074ae6caccc74c32bd6271d4d2
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162044
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76900}
Refactor TryCopyAndConvertArrayToCppBuffer to avoid using a CTypeInfo*
pointer as template argument. Use instead a uint32 encoded value
sufficient to reconstruct the CTypeInfo.
Bug: v8:11739
Change-Id: I74052e59b3fa5ebed00cdb938504ba1947d959d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138832
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76887}
GetWriteBarrierType used to consider the slot so that a barrier is not
triggered for on-stack slots. For strongifying weak collections we want
the write barrier to trigger even if the backing store is only reachable
from stack.
Blink counterpart: crrev.com/c/3162170
Bug: chromium:1244057
Change-Id: I75b1ca62ad5de7bae3d2f4c1a9acce839f3ccdc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162127
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76872}
Removes include now that chrome is not transitively including the header
via v8-inspector.h.
Bug: v8:11965
Change-Id: Ice039f54f2b97e6fba8765c5220d3145c10ba073
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141585
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76693}
Fix delegation to the specific slow-path bailout.
Note: This was not an issue in Blink production code but only when
using `cppgc_enable_object_names = true`.
Bug: chromium:1056170
Change-Id: I00db63f015b60ac2ccd9f80eca80728bc78e9187
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144911
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76692}
Drive-by: Pointer to reference conversions and other smaller cleanups.
Change-Id: I83ed114e4b27d5986a389a9753333716b0e20524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133146
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76615}
Double-checked locking pattern for destruction was missing the acquire
barrier for the initial load.
TSAN complained with a data race where:
T1: ClearAllUsedNodes(), clearing out the node
T2: a. if(GetNodeSafe()) { Lock; ... }
T2: b. operator delete
Since GetNodeSafe() was a relaxed load, operator delete was allowed to
be reordered which raced with ClearAllUsedNodes().
Bug: chromium:1239081, chromium:1242795
Change-Id: I3906555b13cc51538a1a54b7ca481a96d81fd84e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3132264
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76599}
This avoids a benign race in setting the raw pointer inside CTP
destructor by not emitting the write at all. The handle is destructed
which means that we only need to destroy any backing node but may
leave the handle untouched.
Drive-by:
- Add a few more docs.
- Make Clear() thread-safe.
- Make assignment of a sentinel pointer thread-safe.
- Make assignment of a nullptr thread-safe.
Depends on the Blink change: https://crrev.com/c/3116259
Bug: chromium:1242795, chromium:1243350
Change-Id: I8d76da30893c165e3946322b6d02f6ea2c8e529e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114064
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76493}
In a follow-up CL, the backing stores will, when the sandbox is enabled,
be referenced from V8 objects through offsets rather than raw pointers.
For that to work, all backing stores must be located inside the virtual
memory cage. This CL prepares for that.
Bug: chromium:1218005
Change-Id: Ibb989626ed7094bd4f02ca15464539f4e2bda90f
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114136
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76486}
This reverts commit 5a6c7dee4e.
Reason for revert: Speculative: Lots of Chrome crashes:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/13353/overview
Original change's description:
> cppgc: Fix CTP for destruction
>
> This avoids a benign race in setting the raw pointer inside CTP
> destructor by not emitting the write at all. The handle is destructed
> which means that we only need to destroy any backing node but may
> leave the handle untouched.
>
> Drive-by:
> - Add a few more docs.
> - Make Clear() thread-safe.
> - Make assignment of a sentinel pointer thread-safe.
> - Make assignment of a nullptr thread-safe.
>
> Bug: chromium:1242795
> Change-Id: I0d9dafa31c298053e87ba1eb75f99fa6e33fa10b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114134
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76455}
Bug: chromium:1242795
Change-Id: Ia96d66f4908894091a4e498116d9568bd7b0e0a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114058
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76482}
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}
Give a little bit of introduction to Oilpan and provide a few links to
navigate the project.
Bug: chromium:1056170
Change-Id: I4ef8c256c8de7932e3393017be6c58ba48ca45f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114141
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76457}
This avoids a benign race in setting the raw pointer inside CTP
destructor by not emitting the write at all. The handle is destructed
which means that we only need to destroy any backing node but may
leave the handle untouched.
Drive-by:
- Add a few more docs.
- Make Clear() thread-safe.
- Make assignment of a sentinel pointer thread-safe.
- Make assignment of a nullptr thread-safe.
Bug: chromium:1242795
Change-Id: I0d9dafa31c298053e87ba1eb75f99fa6e33fa10b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114134
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76455}
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}
Consider reading the internal node pointer instead of the actual pointer
when trying to figure out whether a node needs to be destroyed. This
preserves the non-atomiticity of the actual pointer which highlights
races using TSAN while fixing destruction.
Bug: chromium:1239081
Change-Id: I1d1fa29d40d86e4b156269abc90142ee71a8d8f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110199
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76415}
This is an internal property that should not be used publicly.
The following methods are going to be deprecated:
- v8::TryCatch::JSStackComparableAddress
- v8::BackupIncumbentScope::JSStackComparableAddress
Change-Id: Iaecfdece4660eaf1aef88121ff0f0c501c0ced5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097451
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76363}
This introduces a new, optional `nonIndexedPropertiesOnly` flag to the
`Runtime.getProperties` inspector request, which tells the inspector to
only report properties whose name is not an (typed) array index. This is
to support retrieving all properties except for the indexed ones when
the DevTools front-end decides to use the array bucketing mechanism.
Previously the DevTools front-end had some quite complicated logic in
place to simulate this via injected JavaScript, but that logic didn't
pick up internal properties and was also interfering with the inherited
accessor mechanism. With this new flag, it's straight-forward to
implement the correct behavior in the DevTools front-end.
The corresponding devtools-frontend CL is https://crrev.com/c/3099011.
Before: https://imgur.com/hMX6vaV.png
After: https://imgur.com/MGgiuJQ.png
Bug: chromium:1199701
Change-Id: Iacbe9756ed8a2e6982efaebe1e7c606d37c05379
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099686
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76360}
ArrayBuffer backing stores will instead use the virtual memory cage and
be referenced through offsets rather than pointers when the sandbox is
enabled. This will be implemented in an independent CL.
Bug: v8:10391
Change-Id: Icc9781003e53c76dbbf4c84ee165151e4182da4b
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086458
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76348}
This is a reland of a3b2c4ec81
The fix is in PS3, for UBSan. We use WriteUnalignedValue for
potentially unaligned memory writes.
Original change's description:
> [wasm][diagnostics] Support WasmCode in gdb JIT integration
>
> - Add new enum WASM_CODE to JitCodeEvent::CodeType
> - Use AddressRegion instead of AddressRange (remove the latter)
> - Change CodeDescription constructor to take an AddressRegion,
> both JIT_CODE and WASM_CODE use this
> - Add a simple mjsunit test that sets --gdbjit to check that
> we don't crash.
> - Add a api test for adding WASM_CODE
>
> Bug: v8:11908
> Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76271}
Bug: v8:11908
Change-Id: I5ded6d01cff40803b2f70525163f760edcf97165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76327}
This commit updates the comment for the AddData methods which currently
refer to GetDataFromSnapshot, and changes them to
GetDataFromSnapshotOnce instead.
Change-Id: Id09d187eccf645338e2c75b8b692c15a904c8357
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2301929
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76310}
