The test does not expect GC to happen while it is running
Bug: v8:10988
Change-Id: Idcd30bde4ae1a7c3386a5d8c4c46e46e839e0fe9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449971
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70316}
When debugging WebAssembly, calls to evaluateOnCallFrame always return
undefined. This CL enables evaluateOnCallFrame for WebAssembly and
creates a proxy object that is injected into the evaluation context.
Bug: chromium:1127914
Change-Id: I3f5cff3be2c9de45c7b1f3f7ed4fc2e1cc545ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429265
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70315}
These three wasm methods do not use the context, but were passed one:
* WasmInt32ToHeapNumber
* WasmFloat32ToNumber
* WasmFloat64ToNumber
Bug: v8:6949, v8:10933
Change-Id: I55e4264f7e06f3fb8338df77d12132c938acfcff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445934
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70314}
This change adds a new code generator, which supports a subset of the
instructions supported by the existing CSAGenerator, and instead of
generating CSA it generates runtime C++ code. The new generator is used
to generate a set of Torque macros that return slices to indexed fields.
These new macros should be sufficient to eventually support
Torque-generated field accessors, BodyDescriptors, verifier functions,
and postmortem field inspection in debug_helper.
Bug: v8:7793
Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70313}
If we're testing printing in UTC timezone, then we have to be careful to
also input the date in UTC, else local timezone will affect the test.
Fixed: chromium:1135116
Change-Id: I49981c263e7b1fa1492b4644c5d4846fd94e5613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448793
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70312}
This was not happening when there was no need to typecheck the entry.
Additional changes:
- Add tests with null table entries for typed and untyped function
tables.
- Allow AddIndirectFunctionTable in wasm-run-utils to specify table
type.
- Add possibility to define tables in test-gc.cc.
- Merge trapTableOutOfBounds with trapInvalidFunc.
- Use trapTableOutOfBounds in call_indirect as appropriate.
- Fix emission of table types in wasm-module-builder.cc.
Bug: v8:9495
Change-Id: I4a857ff4378e5a87dc0646d94b4c75635a43c55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442622
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70311}
Remove the separate Initialize method from Deserializer, opting instead
to pass around SnapshotData where appropriate and pass the isolate
directly into the Deserializer's constructor.
Change-Id: I0092fadd9c81f14b2ce75145fd81af37c3947c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448466
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70310}
Make all writes to JSMember.val_ atomic and atomically check for
emptiness in Trace.
Bug: chromium:1056170
Change-Id: Ia7034b9318df081aa61c9b6664903dd4f73402a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431569
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70309}
This CL extracts weak object worklist related code into separate files
and uses a macro to specify all weak object worklists in a generic way.
The motivation of the refactoring is twofold:
1) We can now enforce that each weak object worklist is updated after
Scavenge. (Forgetting to define the update function causes a link
time error.)
2) The reduced boilerplate will be useful for transitioning to the
new ::heap::base::Worklist.
Change-Id: Ic80a7ccca010c09370d6525f43d78de24192f8ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70308}
As a drive-by, rename "sanity check" to "check" in sharedarraybuffer.
Bug: v8:6949, v8:10933
Change-Id: Ifa2eac381ed309a099b018de4033816ebe3d828d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429410
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70307}
We can use tag dispatching to distinguish between the synchronized and
non-synchronized accessors. Also eliminated the need of adding explicit
"synchronized" in the name when using the macros.
As a note, we currently have one case of using both relaxed and
synchronized accessors (Map::instance_descriptors).
Cleaned up:
* BytecodeArray::source_position_table
* Code::code_data_container
* Code::source_position_table
* FunctionTemplateInfo::call_code
* Map::instance_descriptors
* Map::layout_descriptor
* SharedFunctionInfo::function_data
Bug: v8:7790
Change-Id: I5a502f4b2df6addb6c45056e77061271012c7d90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424130
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70306}
Other WebAssembly tools like wabt and wasmparser ignore empty strings
for local variable and parameter names, and just generate their own
names for it. Update V8 to comply with this convention.
Bug: chromium:1134531
Change-Id: Ic724482d93398feaf6b0797eec5a55f8ca508ca5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448457
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70305}
Instead of loading the map from the feedback vector for monomorphic
access, this CL directly inlines the expected map constant as a static
check.
In case this static check fails, we call out to a builtin which performs
additional dynamic map checks.
There are several dynamic map checks performed by the builtin for various
cases such as:
(a) IC is monomorphic with a map that's different from the initial
static map that we checked, in which case we perform another dynamic
map check.
(b) IC is monomorphic but incoming map is a deprecated map in which case
we call out the runtime to migrate this incoming object to a new map and
then try to handle it.
(c) IC has now transitioned to polymorphic in which we use the old
dynamic polymorphic checks to validate the map and handler.
Bug: v8:10582, v8:9684
Change-Id: Id87265ed513e4aef87b8e66c826afbf10f50a1d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429034
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70304}
Codegen timing and cache ageing are two important parameters for NCI
performance. This adds runtime flags for them:
--turbo-nci-cache-ageing (default: false)
--turbo-nci-delayed-codegen (default: true)
Note the behavioral change of disabling ageing by default for now.
Bug: v8:8888
Change-Id: Id9611185566f5c4828ad48e58c42424833d3323b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438456
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70303}
Rather than having repeated IsFoo checks in PostProcessNewObject, which
means repeated handle accesses, map word accesses, and map pointer
decompressions, cache the instance type once and check it with
InstanceTypeChecker.
This gives a measurable 2-3% improvement in deserialization time (in my
informal local measurements).
Bug: chromium:1075999
Change-Id: I3e11588ad5d1c6ee2bbf93b82fa52c66496a325c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440578
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70301}
Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap,
with a single 'FindOrInsert' that explicitly returns whether an existing
entry was found, or the entry was inserted. This replaces 'Get', which
would return either an initialised or uninitialised entry (and callers
would rely on default initialisation to check this).
Also replace 'Set' with 'Insert', which explicitly requires that the
element didn't exist before. This matches expectations where it was
used (where those weren't replaced wholesale with 'FindOrInsert'), and
makes the naming consistent with 'FindOrInsert'.
Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70300}
Run variant stress_concurrent_allocation in debug mode and with TSAN.
Failing tests will close tree and block CQ.
Bug: v8:10315
Change-Id: I0ba2921a3718a08b88516f209364b52c8817c331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436343
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70299}
We used to have extra data in this but now it's just an indirection to
CodeEntryAndLineNumber so use that everywhere instead.
Change-Id: I6dcedabc1502bc1eed25c05e23f04b996b91bae7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440829
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70294}
`vperm` indices are taken from the five least significant bits
of the input byte. We need to make sure bigger values
are saturated to 31 to make vperm select 0 as the output.
Change-Id: I74715e909e4a50dec23f5423e53254836fe0ff8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2446553
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70292}
Remove a spurious assert probably introduced by a bad merge that
disallowed RO_SPACE sharing when pointer compression is enabled.
Change-Id: I8a59a242667252dcbb098e5be405ac67a4e01a3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445877
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70290}
The TF_BUILTIN version of UntypedParameter is not used anywhere. There's
still CodeAssembler::UntypedParameter which is still in use if a untyped
parameter is required.
Change-Id: I3580e73b781d750878d7bb1b38298d5b82d15f4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445876
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70289}
This is a reland of c4a062a958
which was a reland of 28a30c578c
which was a reland of 5d7a29c90e
Fixes TSAN errors from non-atomic writes in the deserializer. Now all
writes are (relaxed) atomic.
Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c90e
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > Original change's description:
> > > [serializer] Allocate during deserialization
> > >
> > > This patch removes the concept of reservations and a specialized
> > > deserializer allocator, and instead makes the deserializer allocate
> > > directly with the Heap's Allocate method.
> > >
> > > The major consequence of this is that the GC can now run during
> > > deserialization, which means that:
> > >
> > > a) Deserialized objects are visible to the GC, and
> > > b) Objects that the deserializer/deserialized objects point to can
> > > move.
> > >
> > > Point a) is mostly not a problem due to previous work in making
> > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > size before any subsequent allocation/safepoint. We now additionally
> > > have to initialize the allocated space with a valid tagged value -- this
> > > is a magic Smi value to keep "uninitialized" checks simple.
> > >
> > > Point b) is solved by Handlifying the deserializer. This involves
> > > changing any vectors of objects into vectors of Handles, and any object
> > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > the object's address is no longer a stable hash).
> > >
> > > Back-references can no longer be direct chunk offsets, so instead the
> > > deserializer stores a Handle to each deserialized object, and the
> > > backreference is an index into this handle array. This encoding could
> > > be optimized in the future with e.g. a second pass over the serialized
> > > array which emits a different bytecode for objects that are and aren't
> > > back-referenced.
> > >
> > > Additionally, the slot-walk over objects to initialize them can no
> > > longer use absolute slot offsets, as again an object may move and its
> > > slot address would become invalid. Now, slots are walked as relative
> > > offsets to a Handle to the object, or as absolute slots for the case of
> > > root pointers. A concept of "slot accessor" is introduced to share the
> > > code between these two modes, and writing the slot (including write
> > > barriers) is abstracted into this accessor.
> > >
> > > Finally, the Code body walk is modified to deserialize all objects
> > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > during a RelocInfo walk.
> > >
> > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > size rather than byte size -- the size is expected to be tagged-aligned
> > > anyway, so now we get an extra few bits in the size encoding.
> > >
> > > Bug: chromium:1075999
> > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70229}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}
Tbr: jgruber@chromium.org,ulan@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Bug: chromium:1075999
Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70288}
This resolves several races identified by concurrent marking tests.
These include:
(*) Several instances of not using atomic accesses.
(*) Synchronizing page on page creation.
Bug: chromium:1056170
Change-Id: I4a32a44b93a6995a11e3cc75c9446fb8860ae780
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423717
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70287}
Using a OneByte table allows branches to be removed if the function is inlined
in a place where we statically know the character is onebyte.
This adds support for line terminators. To support 2byte line terminators as
well this adds a entries for the lower byte into the table so we can often take
a faster path in that case as well.
Change-Id: Ibd08d540e0e13047d6c1f675c187f14fda4336c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445471
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70286}
It only had one callsite, and that callsite was useless:
%IsValidSmi(two_31) has never returned {true} on any
configuration we have ever shipped.
Bug: v8:10933
Change-Id: I09cdfd7bbd7960d1ec460ad4bd9f0d21e47f7393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434746
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70285}
We clear during sweep so that we are guaranteed the in-construction bit
of newly allocated objects is always 0. The lock sweeping uses for
synchronization assures no data races between clearing and concurrent
marking.
The only exception to that is debug builds that zap on sweep and clear
on allocation. This makes it so that dangling references will most
likely crash in debug builds.
Bug: chromium:1056170
Change-Id: I12597ef76629ec50c6bfc39dc21b68243c4160ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438530
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70283}
In construction objects don't have anything to sync with on the
allocation side since they weren't marked as fully constructed yet.
This could mean the initialization of the marking bit on the mutator
thread and setting the mark bit on a concurrent thread could race
(potentially resulting in losing the mark bit when the gc info index
overwrites it).
This CL fixes this issue by using a set of in construction objects.
In construction objects are no longer marked. Instead they are pushed
to the set and the heap object header is marked when they are popped
from the worklist. Since the set avoids duplicates, this allows us to
both avoid worklist explosion (due to pushing the same in construction
object multiple times) and avoid the data race on the mark bit.
This CL uses an unordered_set to record objects. Synchronization uses
a lock, which could be costly but is not expected to be obtained often.
Bug: chromium:1056170
Change-Id: I366b59f476c166ff06e15b280df9e846034cc6cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437388
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70282}
The lambda used to do more work, now it's just a single function call.
Thus remove the lambda by inlining it into all callers.
Also, get rid of an unneeded parameter on {OnCompilationStopped}.
R=thibaudm@chromium.org
Bug: v8:10933
Change-Id: I2c5bc8dfab7abe47a69c1c3eeb5ec8dd02f503c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440524
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70281}
This reverts commit c4a062a958.
Reason for revert: TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33504
Original change's description:
> Reland^2 "[serializer] Allocate during deserialization"
>
> This is a reland of 28a30c578c
> which was a reland of 5d7a29c90e
>
> The crashes were from calling RegisterDeserializerFinished on a null
> Isolate pointer, for a deserializer that was never initialised
> (specifically, ReadOnlyDeserializer when ROHeap is shared).
>
> Original change's description:
> > Reland "[serializer] Allocate during deserialization"
> >
> > This is a reland of 5d7a29c90e
> >
> > This reland shuffles around the order of checks in Heap::AllocateRawWith
> > to not check the new space addresses until it's known that this is a new
> > space allocation. This fixes an UBSan failure during read-only space
> > deserialization, which happens before the new space is initialized.
> >
> > It also fixes some issues discovered by --stress-snapshot, around
> > serializing ThinStrings (which are now elided as part of serialization),
> > handle counts (I bumped the maximum handle count in that check), and
> > clearing map transitions (the map backpointer field needed a Smi
> > uninitialized value check).
> >
> > Original change's description:
> > > [serializer] Allocate during deserialization
> > >
> > > This patch removes the concept of reservations and a specialized
> > > deserializer allocator, and instead makes the deserializer allocate
> > > directly with the Heap's Allocate method.
> > >
> > > The major consequence of this is that the GC can now run during
> > > deserialization, which means that:
> > >
> > > a) Deserialized objects are visible to the GC, and
> > > b) Objects that the deserializer/deserialized objects point to can
> > > move.
> > >
> > > Point a) is mostly not a problem due to previous work in making
> > > deserialized objects "GC valid", i.e. making sure that they have a valid
> > > size before any subsequent allocation/safepoint. We now additionally
> > > have to initialize the allocated space with a valid tagged value -- this
> > > is a magic Smi value to keep "uninitialized" checks simple.
> > >
> > > Point b) is solved by Handlifying the deserializer. This involves
> > > changing any vectors of objects into vectors of Handles, and any object
> > > keyed map into an IdentityMap (we can't use Handles as keys because
> > > the object's address is no longer a stable hash).
> > >
> > > Back-references can no longer be direct chunk offsets, so instead the
> > > deserializer stores a Handle to each deserialized object, and the
> > > backreference is an index into this handle array. This encoding could
> > > be optimized in the future with e.g. a second pass over the serialized
> > > array which emits a different bytecode for objects that are and aren't
> > > back-referenced.
> > >
> > > Additionally, the slot-walk over objects to initialize them can no
> > > longer use absolute slot offsets, as again an object may move and its
> > > slot address would become invalid. Now, slots are walked as relative
> > > offsets to a Handle to the object, or as absolute slots for the case of
> > > root pointers. A concept of "slot accessor" is introduced to share the
> > > code between these two modes, and writing the slot (including write
> > > barriers) is abstracted into this accessor.
> > >
> > > Finally, the Code body walk is modified to deserialize all objects
> > > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > > during a RelocInfo walk.
> > >
> > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > > size rather than byte size -- the size is expected to be tagged-aligned
> > > anyway, so now we get an extra few bits in the size encoding.
> > >
> > > Bug: chromium:1075999
> > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#70229}
> >
> > Bug: chromium:1075999
> > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70267}
>
> Tbr: jgruber@chromium.org,ulan@chromium.org
> Bug: chromium:1075999
> Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70279}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ib2f01db4cd9b55639d6a4af971bda865edb45e84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445250
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70280}
This is a reland of 28a30c578c
which was a reland of 5d7a29c90e
The crashes were from calling RegisterDeserializerFinished on a null
Isolate pointer, for a deserializer that was never initialised
(specifically, ReadOnlyDeserializer when ROHeap is shared).
Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c90e
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> Original change's description:
> > [serializer] Allocate during deserialization
> >
> > This patch removes the concept of reservations and a specialized
> > deserializer allocator, and instead makes the deserializer allocate
> > directly with the Heap's Allocate method.
> >
> > The major consequence of this is that the GC can now run during
> > deserialization, which means that:
> >
> > a) Deserialized objects are visible to the GC, and
> > b) Objects that the deserializer/deserialized objects point to can
> > move.
> >
> > Point a) is mostly not a problem due to previous work in making
> > deserialized objects "GC valid", i.e. making sure that they have a valid
> > size before any subsequent allocation/safepoint. We now additionally
> > have to initialize the allocated space with a valid tagged value -- this
> > is a magic Smi value to keep "uninitialized" checks simple.
> >
> > Point b) is solved by Handlifying the deserializer. This involves
> > changing any vectors of objects into vectors of Handles, and any object
> > keyed map into an IdentityMap (we can't use Handles as keys because
> > the object's address is no longer a stable hash).
> >
> > Back-references can no longer be direct chunk offsets, so instead the
> > deserializer stores a Handle to each deserialized object, and the
> > backreference is an index into this handle array. This encoding could
> > be optimized in the future with e.g. a second pass over the serialized
> > array which emits a different bytecode for objects that are and aren't
> > back-referenced.
> >
> > Additionally, the slot-walk over objects to initialize them can no
> > longer use absolute slot offsets, as again an object may move and its
> > slot address would become invalid. Now, slots are walked as relative
> > offsets to a Handle to the object, or as absolute slots for the case of
> > root pointers. A concept of "slot accessor" is introduced to share the
> > code between these two modes, and writing the slot (including write
> > barriers) is abstracted into this accessor.
> >
> > Finally, the Code body walk is modified to deserialize all objects
> > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > during a RelocInfo walk.
> >
> > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > size rather than byte size -- the size is expected to be tagged-aligned
> > anyway, so now we get an extra few bits in the size encoding.
> >
> > Bug: chromium:1075999
> > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70229}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}
Tbr: jgruber@chromium.org,ulan@chromium.org
Bug: chromium:1075999
Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70279}
This CL implements passing float parameters to fast API calls by
using the existing representation conversions for double parameters
and then truncating the double to a float.
It also adds float/double tests for fast API calls.
Bug: chromium:1052746
Change-Id: Ibb3ccd173b3807a515adbf38cebaa1cf8e2784b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436333
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70277}
BytecodeGraphBuilder::NewNode already wires up effect and control, so we
don't need to do it manually.
Bug: v8:10933
Change-Id: I454609b10a5748abd13e668780814a4eb6d7cdfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442625
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70276}
Rolling v8/build: 3ede101..9cc0704
Rolling v8/third_party/aemu-linux-x64: oJeWXQJJ1lVY6P7l39pBV-mrbeWlw0swPZQuNmcix5AC..UABC8VAzZj56bPNLe3ou7AIlBjwHbiXOu6R9f5RbZWcC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/0f6ed71..8c88c75
Rolling v8/third_party/depot_tools: 991ead1..69e30b2
Rolling v8/third_party/fuchsia-sdk: 6a38b0e..f8df9ff
Rolling v8/tools/clang: bd8e096..921f371TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I67490c905909fcdcfad45b25f8d5341ec743e7e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443592
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#70275}
It was slightly inconsistent, the sse versions took int8_t, the avx
versions took uint8_t. Consolidate into uint8_t, that allows us to
remove the DCHECK inside of the assembler, and also convert callers to
use uint8_t.
Bug: v8:10933
Change-Id: I125f0d54533b6fde1362e63e96f50fcf2467cac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443494
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70274}
This is a reland of 40af6aeebf
Change from the rollbacked version
- removes the passed test fixed by this PR in test/test262/test262.status
TBR=jkummerow@chromium.org
Original change's description:
> [intl] Impl ECMA402 PR 471 rounding behavior
>
> Fix awkward rounding behavior
> Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
> behavior in NumberFormat when formatting a currency with
> "maximumFractionDigits" set to a value less than 2.
>
> Bug: v8:10844
> Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
> Refs: https://github.com/tc39/ecma402/pull/471
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70270}
Bug: v8:10844
Change-Id: Icfe7363f63d402abccc038e2b8bd78b38d0d9c49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444210
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70273}
Narrowing operations need to sign extend the result.
E.g. for narrowing uint16 to uint8, we compare uint16 to uint8 max,
0xff. The final result should be 0xffffffff (sign extended) since we
try to keep nodes in their sign extended form, to work well with
the rest of the lowering operations.
With this, we pass the last spec test (that is not ignored),
simd_conversions.
Bug: v8:10507
Change-Id: I8914fd69db9378b8244cba5dcacff98d36893649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436613
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70272}
This reverts commit 40af6aeebf.
Reason for revert: Test262 failures, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/2509?
Original change's description:
> [intl] Impl ECMA402 PR 471 rounding behavior
>
> Fix awkward rounding behavior
> Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
> behavior in NumberFormat when formatting a currency with
> "maximumFractionDigits" set to a value less than 2.
>
> Bug: v8:10844
> Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
> Refs: https://github.com/tc39/ecma402/pull/471
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70270}
TBR=jkummerow@chromium.org,ftang@chromium.org,syg@chromium.org
Change-Id: I1cfc05e0e2015ad18c037003c9a9a414e2151e06
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10844
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441549
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70271}
Fix awkward rounding behavior
Change Intl::SetNumberFormatDigitOptions to fix the awkward rounding
behavior in NumberFormat when formatting a currency with
"maximumFractionDigits" set to a value less than 2.
Bug: v8:10844
Change-Id: I2ff4afa9f747cd79cb9964fe4c77a0dd2b8977b5
Refs: https://github.com/tc39/ecma402/pull/471
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70270}
This reverts commit 28a30c578c.
Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?
Original change's description:
> Reland "[serializer] Allocate during deserialization"
>
> This is a reland of 5d7a29c90e
>
> This reland shuffles around the order of checks in Heap::AllocateRawWith
> to not check the new space addresses until it's known that this is a new
> space allocation. This fixes an UBSan failure during read-only space
> deserialization, which happens before the new space is initialized.
>
> It also fixes some issues discovered by --stress-snapshot, around
> serializing ThinStrings (which are now elided as part of serialization),
> handle counts (I bumped the maximum handle count in that check), and
> clearing map transitions (the map backpointer field needed a Smi
> uninitialized value check).
>
> Original change's description:
> > [serializer] Allocate during deserialization
> >
> > This patch removes the concept of reservations and a specialized
> > deserializer allocator, and instead makes the deserializer allocate
> > directly with the Heap's Allocate method.
> >
> > The major consequence of this is that the GC can now run during
> > deserialization, which means that:
> >
> > a) Deserialized objects are visible to the GC, and
> > b) Objects that the deserializer/deserialized objects point to can
> > move.
> >
> > Point a) is mostly not a problem due to previous work in making
> > deserialized objects "GC valid", i.e. making sure that they have a valid
> > size before any subsequent allocation/safepoint. We now additionally
> > have to initialize the allocated space with a valid tagged value -- this
> > is a magic Smi value to keep "uninitialized" checks simple.
> >
> > Point b) is solved by Handlifying the deserializer. This involves
> > changing any vectors of objects into vectors of Handles, and any object
> > keyed map into an IdentityMap (we can't use Handles as keys because
> > the object's address is no longer a stable hash).
> >
> > Back-references can no longer be direct chunk offsets, so instead the
> > deserializer stores a Handle to each deserialized object, and the
> > backreference is an index into this handle array. This encoding could
> > be optimized in the future with e.g. a second pass over the serialized
> > array which emits a different bytecode for objects that are and aren't
> > back-referenced.
> >
> > Additionally, the slot-walk over objects to initialize them can no
> > longer use absolute slot offsets, as again an object may move and its
> > slot address would become invalid. Now, slots are walked as relative
> > offsets to a Handle to the object, or as absolute slots for the case of
> > root pointers. A concept of "slot accessor" is introduced to share the
> > code between these two modes, and writing the slot (including write
> > barriers) is abstracted into this accessor.
> >
> > Finally, the Code body walk is modified to deserialize all objects
> > referred to by RelocInfos before doing the RelocInfo walk itself. This
> > is because RelocInfoIterator uses raw pointers, so we cannot allocate
> > during a RelocInfo walk.
> >
> > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> > size rather than byte size -- the size is expected to be tagged-aligned
> > anyway, so now we get an extra few bits in the size encoding.
> >
> > Bug: chromium:1075999
> > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#70229}
>
> Bug: chromium:1075999
> Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70267}
TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org
Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70268}
This is a reland of 5d7a29c90e
This reland shuffles around the order of checks in Heap::AllocateRawWith
to not check the new space addresses until it's known that this is a new
space allocation. This fixes an UBSan failure during read-only space
deserialization, which happens before the new space is initialized.
It also fixes some issues discovered by --stress-snapshot, around
serializing ThinStrings (which are now elided as part of serialization),
handle counts (I bumped the maximum handle count in that check), and
clearing map transitions (the map backpointer field needed a Smi
uninitialized value check).
Original change's description:
> [serializer] Allocate during deserialization
>
> This patch removes the concept of reservations and a specialized
> deserializer allocator, and instead makes the deserializer allocate
> directly with the Heap's Allocate method.
>
> The major consequence of this is that the GC can now run during
> deserialization, which means that:
>
> a) Deserialized objects are visible to the GC, and
> b) Objects that the deserializer/deserialized objects point to can
> move.
>
> Point a) is mostly not a problem due to previous work in making
> deserialized objects "GC valid", i.e. making sure that they have a valid
> size before any subsequent allocation/safepoint. We now additionally
> have to initialize the allocated space with a valid tagged value -- this
> is a magic Smi value to keep "uninitialized" checks simple.
>
> Point b) is solved by Handlifying the deserializer. This involves
> changing any vectors of objects into vectors of Handles, and any object
> keyed map into an IdentityMap (we can't use Handles as keys because
> the object's address is no longer a stable hash).
>
> Back-references can no longer be direct chunk offsets, so instead the
> deserializer stores a Handle to each deserialized object, and the
> backreference is an index into this handle array. This encoding could
> be optimized in the future with e.g. a second pass over the serialized
> array which emits a different bytecode for objects that are and aren't
> back-referenced.
>
> Additionally, the slot-walk over objects to initialize them can no
> longer use absolute slot offsets, as again an object may move and its
> slot address would become invalid. Now, slots are walked as relative
> offsets to a Handle to the object, or as absolute slots for the case of
> root pointers. A concept of "slot accessor" is introduced to share the
> code between these two modes, and writing the slot (including write
> barriers) is abstracted into this accessor.
>
> Finally, the Code body walk is modified to deserialize all objects
> referred to by RelocInfos before doing the RelocInfo walk itself. This
> is because RelocInfoIterator uses raw pointers, so we cannot allocate
> during a RelocInfo walk.
>
> As a drive-by, the VariableRawData bytecode is tweaked to use tagged
> size rather than byte size -- the size is expected to be tagged-aligned
> anyway, so now we get an extra few bits in the size encoding.
>
> Bug: chromium:1075999
> Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70229}
Bug: chromium:1075999
Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70267}
