Avoid generating switch statements with only a default case. Instead,
when there are no instructions that can trap, simply have
HasMemoryAccessMode() return false. This avoids a MSVC warning when
doing a 32-bit build.
To do this, remove empty TARGET_ARCH_OPCODE_WITH_MEMORY_ACCESS_MODE_LIST
definitions from instruction-codes-$arch.h files.
Change-Id: Ifed76eb9cbca169f30c188c1999e1e9be0b2c6aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3224807
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77441}
Change the logic behind GenerateOneOf so that not only
ref_null would appear almost everytime. Increase the probability
of other alternatives to appear as well.
Change the name of GenerateOptRef to GenerateRef.
Bug: v8:11954
Change-Id: I8bff1661c3d3a91105bca1ffa68e1e9b0b662240
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229367
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77438}
The gdb DCHECK frame skipping automatically skips over all the abort
etc. frames to get you to that DCHECK callsite you're actually looking
for.
However, this is annoying if you tried to call a function with a
breakpoint from the gdb prompt; the frame skipping wold skip over your
breakpoint back up to the failing DCHECK.
Now, we abort the frame walk on dummy frames inserted by gdb execution.
Change-Id: I2cf89ea9219374ad7c562c6eb13afe471038b033
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229376
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77436}
... by updating the checks for not_mapped_symbol root and using proper
cage base values depending on the host object type.
Bug: v8:11880
Change-Id: I28908cbb5b1023addaee248028661d480734e29c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222760
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77435}
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}
1. Stress snapshot discards code on SFIs, which breaks flushing
invariants. Add --stress-snapshot to those invariants.
2. Another test failing on IsScript, added it to the disabled list.
Change-Id: Ic415923a9cc96d34b74f7450b29be99c1b53d077
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229375
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77430}
This CL improves wasm inlining heuristics in Turbofan, for an average
8,5% performance improvement in selected benchmarks.
Changes:
- In WasmInliner::Reduce(), only collect inlining candidates into a
priority queue, according to WasmInliner::LexicographicOrdering.
Move actual inlining to Finalize().
- Remove the InlineFirstFew heuristic. Add two limits to inlining:
Maximum relative size increase (reversely proportional to the function
size), and absolute size increase.
- Pass information about call frequency from liftoff-collected feedback
to the WasmInliner though the wasm module.
- Run wasm inlining along other optimizations in the pipeline.
- Split inlining and speculative inlining tests.
Bug: v8:7748, v8:12166
Change-Id: Iccee22093db765981889a24451fb458dfce1f1a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222764
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77428}
This reverts commit 929b83fb7b.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/18725/overview
Original change's description:
> [heap] Attach to shared isolate after setting up main thread
>
> Attach to the shared isolate after the main thread was set up. Otherwise
> it could happen that a shared GC initiated from another isolate might
> see no threads are running and performs the safepoint operation in the
> middle of isolate deserialization.
>
> We use DisallowSafepoints to check that the isolate doesn't join a
> global safepoint before deserialization is complete. DisallowSafepoints
> used to prevent only invocations of Safepoint() but was updated to
> also prevent Park() and Unpark() invocations. Each state change could
> cause the thread to reach a safepoint, which would allow a shared GC
> to run.
>
> We now also DCHECK that every isolate has at least one local heap and
> that shared collections aren't started before deserialization is
> complete.
>
> Bug: v8:11708
> Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77424}
Bug: v8:11708
Change-Id: I0633150b6b40b297a335a39bf1a087ca93592e04
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3225937
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77425}
Attach to the shared isolate after the main thread was set up. Otherwise
it could happen that a shared GC initiated from another isolate might
see no threads are running and performs the safepoint operation in the
middle of isolate deserialization.
We use DisallowSafepoints to check that the isolate doesn't join a
global safepoint before deserialization is complete. DisallowSafepoints
used to prevent only invocations of Safepoint() but was updated to
also prevent Park() and Unpark() invocations. Each state change could
cause the thread to reach a safepoint, which would allow a shared GC
to run.
We now also DCHECK that every isolate has at least one local heap and
that shared collections aren't started before deserialization is
complete.
Bug: v8:11708
Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77424}
When copying properties, it should never happen that source == target.
Add a CHECK to assert this assumption.
Bug: chromium:1260129
Change-Id: Ia5248e4363d85e13052db726fb7143897cea9c87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226779
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77418}
Avoid repeated collisions when the name doesn't hold much entropy.
This is typically the case with minified sources where 1 or 2 letter
names are used very frequently.
Bug: v8:12316
Change-Id: I20df3a6b0c5daf7975668d25404eca94a1230fe0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222759
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77416}
This reverts commit 7366f6e204.
Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties
Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
> defined by the current class itself, so there might be (for example)
> strong fields before kStartOfStrongFieldsOffset if they were defined
> by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
> using the keyword `weak`, which indicates fields with *custom*
> weakness semantics (those that should be visited with
> IterateCustomWeakPointers), not those that may contain standard weak
> pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
> like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}
Bug: v8:7793
Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783
Auto-Submit: Leszek Swirski <leszeks@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>
Cr-Commit-Position: refs/heads/main@{#77415}
GetUnusedRegister may spill registers and thus modify stack slots.
Therefore, we have to call it before fetching stack slots.
This is another instance of
https://chromium-review.googlesource.com/c/v8/v8/+/3217199.
Bug: v8:7748
Change-Id: I9ff28b26f2dce93ef7b71c1100d9bf88f7c2f7c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226327
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77414}
https://crrev.com/c/3222763 has added a new global value `TB`
which is the same as our `test block` opcode. Cl is adding an
underscore to resolve the naming issue.
Change-Id: I4744f14dd594d4a58ed14d7651a6b7a0cad62ba8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226801
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77413}
This adds a few more trace events, also tracing the number of wrappers.
This can help to understand instantiation time better.
R=ahaas@chromium.org
Bug: v8:12287
Change-Id: Ic1a03b2e278af64908f0dc45cd5db60ecf7c79f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226323
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77412}
Torque currently generates constants like kStartOfWeakFieldsOffset and
kEndOfStrongFieldsOffset, which can be used when writing custom
BodyDescriptors. However, these offsets have some potentially confusing
behaviors:
* They don't take inheritance into account and describe only the fields
defined by the current class itself, so there might be (for example)
strong fields before kStartOfStrongFieldsOffset if they were defined
by a superclass.
* kStartOfWeakFieldsOffset points to the first field defined in Torque
using the keyword `weak`, which indicates fields with *custom*
weakness semantics (those that should be visited with
IterateCustomWeakPointers), not those that may contain standard weak
pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
like to also rename `weak` to `@customWeak`.)
Given that these constants have very low usage and somewhat bizarre
semantics, I propose that we remove them. This change does so, and
updates the existing usages to either define the required constants
directly in C++ or not use them. I know that defining these constants in
C++ is more brittle, but I think that brittle and clear is better than
automatic and incomprehensible.
Bug: v8:7793
Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77411}
This makes it easier to see if a module is taken from the cache.
R=thibaudm@chromium.org
Bug: v8:12287
Change-Id: I6b7acf15f1aa20f6531d746d37890608462606de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226326
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77410}
Array spread syntax `[...obj]` is compiled to a special bytecode that
tries to take fast-paths for values special kinds of `obj`s, including
Set, Map, and Array iterator instances. But these fast-paths skip the
side-effect checks of `Runtime.evaluate` and friends, and thus lead to
surprises for developers.
This CL alters the behavior to always call the `next()` builtins when
the debugger is active to make sure we catch the side effects correctly.
Fixed: chromium:1255896
Change-Id: If3fc48a119cfa791c4fde7b5c586acc22dd973e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226329
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77409}
Port 255aaed95b
Port 6bd44dfe57
Change-Id: I9d57cf7782c267bda4532d0408e69b671e6001f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220271
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77407}
In order to avoid namespace pollution and compilation overhead it is
desirable to avoid include windows.h, and this enforces that.
Bug: chromium:796644
Change-Id: I7fdcd3c182a77cee03672bc4324b9e21566896d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3223960
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77404}
There is no need to wrap the cage's page allocator into a
LsanPageAllocator as that page allocator ultimately relies on the
platform page allocator to obtain pages. As the platform page allocator
will be a LsanPageAllocator when LSAN is enabled, it will already take
care of marking the pages as root regions with LSAN.
luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Bug: chromium:1218005
Change-Id: I62b5da9cb320e5012a657951c0d4c85a1bb2b3fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222761
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77403}
On Windows pre 8.1, userspace is limited to 8TB of virtual address
space. Take that into account when determining the size and/or placement
of the virtual memory cage.
Bug: chromium:1218005
Change-Id: Idda94534cad67dc2db77e9ba459e3a4b239dac2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222763
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77402}
4 instructions, i8x16, i16x8, i32x4, i64x2 relaxed lane select. These
instructions only guarantee results when the entire lane is set or
unset, so vpblendvb will give correct results for all of them.
Bug: v8:12284
Change-Id: I76959a23f2d97de8ecc3bef43d138184484e3c4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207006
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77401}
--trace-wasm-compilation-times: print one line per compiled function
with basic performance information. Useful for narrowing down
functions of interest before investigating them in more depth.
--wasm-tier-up-filter=N: only tier up function #N. Useful for focusing
features like --turbo-stats-wasm on a particular function.
Change-Id: Iaddb29bf815f4de8381a08e29187e96cc9945779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086341
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77399}
The virtual memory cage supports a fallback mode that attempts to obtain
memory pages within a specific virtual address range by using
PageAllocator hints. However, Prior to this CL, the default
PageAllocator on Fuchsia would ignore hints alltogether, preventing
these mechanisms from working there.
Ultimately, on Fuchsia it would probably be better to manage the virtual
memory cage purely through VMARs instead of actually creating pseudo
mappings just to reserve virtual address space as is currently done
through the PageAllocator. This will require broader changes though, so
in the meantime, sticking to the current PageAllocator API is probably
the best option.
Bug: chromium:1218005
Change-Id: I821cfbb815d81479c3b3310296302addbb9cd8f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220340
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77398}
Since we introduced `array.init` as a way to create fully initialized
arrays, immutable arrays are no longer useless, and they enable certain
static optimizations, so this patch allows them.
Bug: v8:7748
Change-Id: I404aab60099826f4bd83cf54e5e1acbc38a3ca9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221151
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77397}
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}
Port: 1cd7a58223
Original Commit Message:
Class Constructors are special, because they are callable but [[Call]]
raises an exception. Instead of checking if a JS function is a class
constructor for every JS function call, this CL adds a new instance
type for class constructors.
This way we can use a fast instance type range check for the common
case, and only check for class constructors in the uncommon case were
a class constructor is called and when we need to raise an exception.
Change-Id: I8f11416124a1eefc4ba63423747686bc0b519bb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218711
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77395}
... into UNIQUE_LEAF_INSTANCE_TYPE_MAP_LIST_GENERATOR and the rest
where the former list contains only those maps which have 1:1 relation
to instance type values.
Bug: v8:11880
Change-Id: Ibe20ec7a7c432680dcf23a5c0102ae89c0689d47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218065
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77394}
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}
