This CL adds decoding and code generation for the table.size
instruction.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I0e689a993d25db72281ebba0854454be12f4d350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593302
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61195}
This CL add decoding and code generation for the table.grow
instruction. For code generation we just generate a runtime
call. The implementation is quite straight-forward. However,
I did several small cleanups along the way. I hope it's still
acceptable. I could also split out some cleanups into separate
CLs.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: Id885b7e70eb4f5bccfe779eb216f7cc9302ea3a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593078
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61192}
On Windows, expanding the stack by more than 4 KB at a time can cause
access violations. This change fixes a few known cases (and includes
unit tests for those), and attempts to make stack expansion more
consistent overall by using the AllocateStackSpace helper method
everywhere we can, even when the offset is a small constant.
On arm64, there was already a consistent method for stack pointer
manipulation using the Claim and Drop methods, so Claim is updated to
touch every page.
Bug: v8:9017
Change-Id: I2dbbceeebbdefaf45803e9b621fe83f52234a395
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570666
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61186}
When asked to start at the receiver and the receiver is a primitive, the
dependency should be taken on the primitive map (which is a no-op)
rather than the wrapper object's map.
Bug: chromium:958716
Change-Id: I9c8b2b56436d134b2f79dbe458c0c527fe6d17a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593086
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61174}
This reverts commit ad44c258d7.
Reason for revert: Missed some users: crbug.com/v8/9105
Original change's description:
> [typedarray] Make JSTypedArray::length authoritative.
>
> This is the first step towards full huge typed array support in V8.
> Before this change, the JSTypedArray::length and the elements backing
> store length (FixedTypedArrayBase::length) were used more or less
> interchangeably to determine the number of elements in a JSTypedArray.
>
> With this change we disentangle these two lengths, and instead make
> JSTypedArray::length authoritative. For on-heap typed arrays, the
> FixedTypedArrayBase::length will remain the number of elements in the
> backing store, but for the off-heap typed arrays, this length will be
> set to 0 (matching the fact that the FixedTypedArrayBase instance does
> not contain any elements itself).
>
> This also unifies the JSTypedArray::set_/length() and length_value()
> methods to only have JSTypedArray::set_/length() which returns/takes
> size_t values. Currently this still requires the values to be in Smi
> range, but later we will extend this to allow arbitrary size_t values
> (in the safe integer range).
>
> Bug: v8:4153, v8:7881
> Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107
> Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60648}
TBR=jarin@chromium.org,titzer@chromium.org,hpayer@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
TBR=jarin@chromium.org, szuend@chromium.org
Bug: v8:4153, v8:7881
Change-Id: I96992bff15b4a2765ae4a557d2c37e78269c927d
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593294
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61172}
The problem is with element kinds transitions without going through
runtime (i.e., IC or optimizing compiler).
Bug: chromium:952682
Change-Id: I6fe2bb30a0ea6fecb8f6e0750427cc50cc50f9e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593083
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61158}
- Add missing uses of MapInference::NoChange.
- Insert map checks even if inferred maps were reliable, because
they were inferred for an earlier effect input.
Bug: chromium:958420, chromium:958350, v8:9197
Change-Id: Id7677b1fc6f1e09dc12ae178f1155e4245b4e3e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593077
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61157}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall
Bug: v8:8801, v8:8394
Change-Id: I1f84477a8cef27b4cff61b54daf6fe1a9e5f8e76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591775
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61148}
This is a reland of 9284ad5731, after
adding a missing speculation mode check in ReduceCallApiFunction.
Original change's description:
> [turbofan] Avoid raw InferReceiverMaps in JSCallReducer
>
> Instead provide an abstraction that makes it hard to forget
> dealing with unreliable maps.
>
> This also fixes a deopt loop in Function.prototype.bind and
> one in Array.prototype.reduce.
>
> Bug: v8:9137
> Change-Id: If6a51182c8693a62e9fb6d302cec19b4d48e25cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578501
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61106}
Tbr: jarin@chromium.org
Bug: v8:9137, v8:9197
Change-Id: I0db68d267055969553c0c1b85fad7b909075c062
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1589976
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61140}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall
Bug: v8:8801, v8:8394
Change-Id: I81918f174b2f97cbaa8b8ef2e459080c2581f535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588415
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61122}
This reverts commit 9284ad5731.
Reason for revert: breaks blink tests:
https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Win/16839
Original change's description:
> [turbofan] Avoid raw InferReceiverMaps in JSCallReducer
>
> Instead provide an abstraction that makes it hard to forget
> dealing with unreliable maps.
>
> This also fixes a deopt loop in Function.prototype.bind and
> one in Array.prototype.reduce.
>
> Bug: v8:9137
> Change-Id: If6a51182c8693a62e9fb6d302cec19b4d48e25cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578501
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61106}
TBR=jarin@chromium.org,neis@chromium.org
Change-Id: I97e0f47fb82eda76656905a3f7cc494babd92be6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9137
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588433
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61118}
Fix recognition of lazy functions when {--wasm-lazy-compilation} is
used.
Bug: chromium:956771
Change-Id: I3f9bb25ccf3920a6c3d266876faace8841dcdc61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585843
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Frederik Gossen <frgossen@google.com>
Cr-Commit-Position: refs/heads/master@{#61114}
This CL refactors WasmTableObject::Grow to make it usable for the
table.grow instruction of WebAssembly.
The refactored version of WasmTableObject::Grow does additionally:
* Check if growing is possible
* Grow the FixedArray backing store of the table and initialize the new
fields.
* Calculate the return value of WasmTableObject::Grow.
R=jkummerow@chromium.org
Bug: v8:7581
Change-Id: Ic6c867b96c30bd987ea281d5b3515a04bc5a3900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588136
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61112}
Instead provide an abstraction that makes it hard to forget
dealing with unreliable maps.
This also fixes a deopt loop in Function.prototype.bind and
one in Array.prototype.reduce.
Bug: v8:9137
Change-Id: If6a51182c8693a62e9fb6d302cec19b4d48e25cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1578501
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61106}
Ignore the error type in {assertThrows} only if it was not passed as an
argument. If users do not care about the error type they can user the
generic type {Error}. Before this change, an undefined error type would
simply be ignored. A simple typo could therefore disable the error type
assertion without being recognized.
Change-Id: I9becfd0bf14dcaa511854e65ff94f94481cc79b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585855
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61105}
This adds a new %_CopyDataProperties intrinsic, that reuses most of the
existing machinery that we already have in place for Object.assign() and
computed property names in object literals. This speeds up the general
case for object spread (where the spread is not the first item in an
object literal) and brings it on par with Object.assign() at least - in
most cases it's significantly faster than Object.assign().
In the test case [1] referenced from the bug, the performance goes from
objectSpreadLast: 3624 ms.
objectAssignLast: 1938 ms.
to
objectSpreadLast: 646 ms.
objectAssignLast: 1944 ms.
which corresponds to a **5-6x performance boost**, making object spread
faster than Object.assign() in general.
Drive-by-fix: This refactors the Object.assign() fast-path in a way that
it can be reused appropriately for object spread, and adds another new
builtin SetDataProperties, which does the core of the Object.assign()
work. We can teach TurboFan to inline Object.assign() based on the new
SetDataProperties builtin at some later point to further optimize
Object.assign().
[1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
Bug: v8:9167
Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61100}
Allow for a third compilation strategy that compiles baseline code
lazily but initiates top tier compilation immediately. The strategy aims
at reducing startup time.
Bug: v8:9003
Change-Id: Ifd2060b25386c5221a45f6038c3849afeb956e69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571620
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Frederik Gossen <frgossen@google.com>
Cr-Commit-Position: refs/heads/master@{#61077}
This CL just updates the map to its non-deprecated counterpart
before adding the integrity level transition.
Bug: chromium:956426
Change-Id: I0aaaeb0451aed28c8893968bbcd9f6eb327da18b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585858
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61057}
This enables constant field tracking unconditionally.
TBR=jgruber@chromium.org
Bug: v8:8361
Change-Id: I02f35827d860c3e0f18a3d55cb156c088d48bc94
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585730
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61055}
The function {memory_copy_wrapper} is called directly from WebAssembly.
Before calling {memory_copy_wrapper} we do not reset the
tread-in-wasm flag. On asan builds on Windows this causes the problem
observed in the crash report.
My theory is the following: asan on Windows uses exceptions to allocate
shadow memory lazily. When {memory_copy_wrapper} accesses memory, asan
causes an exception to allocate shadow memory. This exception is first
caught by the WebAssembly trap handler, which resets the
thread-in-wasm flag but then does not handle the exception because it
cannot find a proper landing pad. Asan then handles the exception and
continues execution. However. the thread-in-wasm flag is not set
anymore. A later check of the thread-in-wasm flag then fails.
This CL disables asan for {memory_copy_wrapper} and thereby fixes the
problem. As indicated above, another solution would be to reset and set
the thread-in-wasm flag before and after the call to the C function,
respectively. However, we do not do that for other uses of direct calls
to C.
R=binji@chromium.org
Bug: chromium:952342
Change-Id: I2adb2eccf2ac25be58392d21f8f43a04414c7811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584326
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61040}
This is a reland of 3d846115d6
Reland changes mjsunit.status to skip the regression test on
all bots except ASAN.
Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
>
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
>
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
>
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
>
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
>
> R=neis@chromium.org, petermarshall@chromium.org
>
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}
Bug: v8:9161
Change-Id: Idffc3fbb5f28f4966c8f1ac6770d5b5d6003a7e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583726
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61011}
This reverts commit 3d846115d6.
Reason for revert: The test hangs flakily on windows:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20612https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/33147https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19945
Original change's description:
> [typedarray] Fix crash when sorting SharedArrayBuffers
>
> TypedArray#sort has a fast-path when the user does not provide a
> comparison function. This fast-path utilizes std::sort which operates
> directly on the raw data. Per spec, std::sort requires the "less than"
> operation to be anti-symmetric and transitive.
>
> When sorting SharedArrayBuffers (SAB) that are concurrently modified during
> sorting, the "less than" operator stops being consistent as the
> underlying data is constantly modified. This breaks some invariants
> in std::sort resulting in infinite loops or straight out segfaults.
>
> This CL fixes this by copying the data before sorting SABs and
> writing the sorted result back.
>
> Note: The added regression test is tailored for ASAN bots as a
> normal build would need too many iterations to consistently crash.
>
> R=neis@chromium.org, petermarshall@chromium.org
>
> Bug: v8:9161
> Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61004}
TBR=neis@chromium.org,petermarshall@chromium.org,szuend@chromium.org
Change-Id: I046da3e4228bb1a8a3aa89d9c9d8de11875a9273
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9161
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583725
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61007}
It shipped in Chrome 73.
Bug: v8:6890
Change-Id: Idd8c98cf05a0d6e8fa58c5b0a34d079631f68b1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1582879
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61005}
TypedArray#sort has a fast-path when the user does not provide a
comparison function. This fast-path utilizes std::sort which operates
directly on the raw data. Per spec, std::sort requires the "less than"
operation to be anti-symmetric and transitive.
When sorting SharedArrayBuffers (SAB) that are concurrently modified during
sorting, the "less than" operator stops being consistent as the
underlying data is constantly modified. This breaks some invariants
in std::sort resulting in infinite loops or straight out segfaults.
This CL fixes this by copying the data before sorting SABs and
writing the sorted result back.
Note: The added regression test is tailored for ASAN bots as a
normal build would need too many iterations to consistently crash.
R=neis@chromium.org, petermarshall@chromium.org
Bug: v8:9161
Change-Id: Ic089928652f75865bfdb11e7453806faa6ecb988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581641
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61004}
This fixes the bounds check for the 'in' operator to handle the negative
index case properly (by using the same machinery as the potentially
out-of-bounds loads/stores use).
Bug: chromium:952586
Change-Id: I2225acae8be7dcedbcde745e8ef202e789085041
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581179
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60978}
This extends the existing test coverage of interactions between the
exception handling and the reference type proposal. Now "any-func" and
"except-ref" can both be encoded as an exception value. Missing switch
cases have been added.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-anyref[-interpreter]
BUG=v8:8091,v8:7581
Change-Id: Ie2e9819fe66b4daab623390f27bb19007131f619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1581600
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60977}
In the PerformPromise{All, Race, AllSettled} operations, the resolve
property of the constructor is looked up only once.
In the implementation, for the fast path, where the constructor's
resolve property is untainted, the resolve function is set to undefined.
Since undefined can't be a valid value for the resolve function,
we can switch on it (in CallResolve) to directly call the PromiseResolve
builtin. If the resolve property is tainted, we do an observable property
lookup, save this value, and call this property later (in CallResolve).
I ran this CL against the test262 tests locally and they all pass:
https://github.com/tc39/test262/pull/2131
Spec:
- https://github.com/tc39/ecma262/pull/1506
- https://github.com/tc39/proposal-promise-allSettled/pull/40
Bug: v8:9152
Change-Id: Icb36a90b5a244a67a729611c7b3315d2c29de6e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1574705
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60957}
