This reverts commit a31a623047.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21332
Original change's description:
> [ia32] Remove poisoning logic on ia32
>
> Poisoning has been disabled by default on ia32 a while ago. This CL
> removes its logic from ia32 code generation, which will let us move
> towards fuller (and unconditional) root register support.
>
> Bug: chromium:860429, v8:8254
> Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
> Reviewed-on: https://chromium-review.googlesource.com/c/1296131
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56978}
TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org
Change-Id: I305e9e1719fb4b3f8ef267c232723db9b52966e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:860429, v8:8254
Reviewed-on: https://chromium-review.googlesource.com/c/1299015
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56980}
Resets the isolate's context to nullptr in debug builds during bytecode finalization
to ensure that we don't rely on the native context during context independent
unoptimized compilation.
BUG=chromium:898076, v8:8041
Change-Id: Ifaa5006a7a3d31d7fbd535ebb63f8889c75526c4
Reviewed-on: https://chromium-review.googlesource.com/c/1297961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56979}
Poisoning has been disabled by default on ia32 a while ago. This CL
removes its logic from ia32 code generation, which will let us move
towards fuller (and unconditional) root register support.
Bug: chromium:860429, v8:8254
Change-Id: I8f672cf48a6ffc7bf21e7794c1b7463d7f8b9594
Reviewed-on: https://chromium-review.googlesource.com/c/1296131
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56978}
The flag was only there to tell whether the {AsyncCompileJob} needs to
be kept alive. We already have this information in all the other fields
of the {AsyncCompileJob}, thus remove it.
R=ahaas@chromium.org
Bug: v8:8238
Change-Id: I8d1d76ba8d622d1816c240e7a824ecf31c3b1ce5
Reviewed-on: https://chromium-review.googlesource.com/c/1297957
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56977}
This is a reland of c92a1dda41
Original change's description:
> [cpu-profiler] Fix a bug which caused a pure virtual function call
>
> We need to remove each Sampler from the SamplerManager before we call
> the Sampler destructor. This is because the signal handler can interrupt
> the destructor, and call DoSampler(), which calls sampler->SampleStack()
> on the sampler being destructed, causing general unhappiness and
> "Pure virtual function called!" crashes.
>
> Bug: v8:8346, v8:5193
> Change-Id: Iaa595a196eab33fb1af31584e9a68fd1ce0a18f6
> Reviewed-on: https://chromium-review.googlesource.com/c/1293949
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56882}
TBR=yangguo@chromium.org
Bug: v8:8346, v8:5193
Change-Id: I9878f65c868ff1aed6f3a587cba688c4241bad8c
Reviewed-on: https://chromium-review.googlesource.com/c/1298893
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56976}
It's unnecessary to buffer in the zone, and using a deque is more expensive
than an std::vector as a stack since we reuse areas very frequently. The
top-of-stack that the State keeps track of is now simply tracked in the state,
with a scope_depth_ counter to figure out if the fni_ is "open" (has an active
state).
Change-Id: I29ad3db7520340b8fe035feed400178bd50785bc
Reviewed-on: https://chromium-review.googlesource.com/c/1298894
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56974}
Replace the explicit ok tracing by setting the scanner to fail, allowing us to
return automatically. RETURN_IF_PARSE_ERROR is now used instead of CHECK_OK to
verify if the parser failed.
In a follow-up CL we'll merge RETURN_IF_PARSE_ERROR after Expect* into an
EXPECT* macro. We'll keep (for now) RETURN_IF_PARSE_ERROR that guard uses of
possible NullExpression (e.g., impl()->IsIdentifier(...)). All other RETURN_IF*
will be removed. Uses after failure can likely later be fixed too by introducing
a FailureExpression.
Bug: v8:8363 ,v8:7926
Change-Id: I9896449eb9be476c453da4417a0bfd17c169ff38
Reviewed-on: https://chromium-review.googlesource.com/c/1294649
Commit-Queue: Florian Sattler <sattlerf@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56972}
Check for is_javascript in Debug::AllFramesOnStackAreBlackboxed,
instead of assuming all frames are javascript frames.
Fix is thanks to dgozman: https://crbug.com/896093#c3
Bug: chromium:896093
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I6b735d904c3fd036d4589d65f10673b81b8f326c
Reviewed-on: https://chromium-review.googlesource.com/c/1295552
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56970}
This would allow SP to be a nonsense value, which would confuse the CPU
profiler when the signal handler read the SP before it was restored.
Bug: v8:8355
Change-Id: If108c8cf00467904fe0f4f26fddc2e3122afcd93
Reviewed-on: https://chromium-review.googlesource.com/c/1298032
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56967}
This allows us to use one underlying buffer rather than 3, and allows memory to
be freed as we're growing the vector.
Change-Id: I45c178a31e8f6d3ee44d3319ce8bca2db2460d33
Reviewed-on: https://chromium-review.googlesource.com/c/1297328
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56966}
This is a reland of fcbb023b0e
Original change's description:
> Add Windows ARM64 ABI support to V8
>
> This change added Windows ARM64 ABI support, major things are:
> 1. Excluding x18 register from any usage because it is reserved as
> platform register. Preserve alignment after the change.
> 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is
> still LLP64.
> 3. Stack guard page probe for large allocation on stack.
>
> Reference:
> Windows ARM64 ABI:
> https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017
>
> Bug: chromium:893460
> Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e
> Reviewed-on: https://chromium-review.googlesource.com/c/1285129
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56881}
CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe
TBR=mlippautz@chromium.org
Bug: chromium:893460
Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52
Reviewed-on: https://chromium-review.googlesource.com/c/1297300
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56965}
This CL gives a first look at the new way to represent tagged object
pointers in C++.
It adds infrastructure in Handles and the garbage collector to deal
with the new object type, and ports a first class to the new world.
Design overview: https://goo.gl/Ph4CGz
Bug: v8:3770
Change-Id: I3e37fbf399612f95540cb386710a595069fb9d55
Reviewed-on: https://chromium-review.googlesource.com/c/1292673
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56964}
Add position to the return of %SegmentIterator%.next()
which newly added to the spec in
https://github.com/tc39/proposal-intl-segmenter/pull/42
Bug: v8:8305
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I8de7102acb670a6c529ab3e35601c78a8dc7703c
Reviewed-on: https://chromium-review.googlesource.com/c/1278636
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56963}
Remove TODO that is already done
Uncomment two working tests.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icb28d84e92812996c2928e90961d75508ba4c401
Reviewed-on: https://chromium-review.googlesource.com/c/1296933
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56961}
Creates the hash_seed byte array in RO_SPACE and moves the root from
STRONG_MUTABLE_IMMOVABLE_ROOT_LIST to STRONG_READ_ONLY_ROOT_LIST.
Bug: v8:8191
Change-Id: I3b044fbb3e51eb5d21ac2e68a54076623865b9d2
Reviewed-on: https://chromium-review.googlesource.com/c/1297959
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56960}
BuildClassBoilerplate accessed the native context to get the
class_function_descriptors. Baseline compilation should be native context
independent, so we shouldn't access the native context at all. As it happens,
class_function_descriptors wasn't used so can just be removed.
BUG=chromium:898076, v8:8041
Change-Id: If9c0edf3dfde68c76ea87820f9d4b080aac6d60e
Reviewed-on: https://chromium-review.googlesource.com/c/1298033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56958}
There are several core changes in this stub:
1) add a version of KeyedStoreGenericGenerator::SetPropertyInLiteral()
which supports indexed properties directly, witthout KeyedStore
2) add a code stub for SetPropertyInLiteral which uses the version
supporting indexed properties
3) Use the code stub in CloneObjectIC, rather than using the smaller
special-cased version which does not handle Names.
Item 1) involves a refactoring which adds a nice way to reuse code in
KeyedStoreGenericAssembler, which allows deleting a bunch of copy/pasted
code. This makes it easy to reuse the index handling in
KeyedStoreGeneric() without adding adding a bunch more duplicated
handling. Because of this, I consider this to be somewhat of a cleanup,
though if the copied code is preferred, I'm happy to revert to that.
Item 2) is needed for Object.fromEntries(), as it's better to not
require falling back to the slow path if a key happens to be an Smi ---
but this is also optional.
Item 3) benefits the codebase by allowing Object.fromEntries() to use
this fast path without calling into the runtime, and without duplicating
code which is also used by CloneObjectIC.
I am skeptical that this should affect performance significantly. I've
run ObjectLiteralSpread tests, and the mean of scores over 100 runs is
somewhat surprising: CloneObjectIC --- the only user of this code,
has an increased average score, while the polyfill cases score slightly
worse --- However, the overall changes are small and likely flukes.
The complete processed test output is below:
```
// Mean of 100 runs of each benchmark
Babel-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 11530.87 | 12142.92 | -5.04%
-----+---------------------------+---------------------------+-------
BabelAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 10881.41 | 11260.81 | -3.37%
-----+---------------------------+---------------------------+-------
ObjectAssign-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 6188.92 | 6358.55 | -2.67%
-----+---------------------------+---------------------------+-------
ObjectAssignAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 6112.80 | 6275.54 | -1.61%
-----+---------------------------+---------------------------+-------
ObjectSpread-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 51942.93 | 50713.17 | +3.46%
-----+---------------------------+---------------------------+-------
ObjectSpreadAndOverwrite-ObjectLiteralSpread:
-----+---------------------------+---------------------------+-------
| With patch | Without patch | diff
Mean | 51375.23 | 50833.29 | +2.09%
-----+---------------------------+---------------------------+-------
```
BUG=v8:8238, v8:8021
R=ishell@chromium.org, jkummerow@chromium.org
Change-Id: I43e102fc461ffd389b5d6810a73f86e5012d7dee
Reviewed-on: https://chromium-review.googlesource.com/c/1277751
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56957}
This adds back another register to the record write stub to have one
additional register on top of the parameter register as allocation
general purpose register. It has only been recently reduced to just four
registers due to embedded builtins. This is needed to be able to tail
call a record write stub.
R=ulan@chromium.orgCC=jgruber@chromium.org
BUG=v8:8341
Change-Id: Id16f9e96d611a871fbe1180581eaf14275a7332e
Reviewed-on: https://chromium-review.googlesource.com/c/1297955
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56955}
GN should understand action outputs, so the header generated by the
run_torque action do not need to be separately listed in another
source_set.
Change-Id: I309e8c012eb0a0597a247806d36658c1d6e5d97b
Reviewed-on: https://chromium-review.googlesource.com/c/1297680
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56953}
This changes the ReceiverOrOddball feedback on JSStrictEqual to
ReceiverOrNullOrUndefined feedback, which can also safely be
consumed by JSEqual (we cannot generally accept any oddball here
since booleans trigger implicit conversions, unfortunately).
Thus we replace the previously introduced CheckReceiverOrOddball
with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since
we will no longer collect Oddball feedback separately.
TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into
a sequence like this:
```
left = CheckReceiverOrNullOrUndefined(left);
right = CheckReceiverOrNullOrUndefined(right);
result = if ObjectIsUndetectable(left) then
ObjectIsUndetectable(right)
else
ReferenceEqual(left, right);
```
This significantly improves the peak performance of abstract equality
with Receiver, Null or Undefined inputs. On the test case outlined in
http://crbug.com/v8/8356 we go from
naive: 2946 ms.
tenary: 2134 ms.
to
naive: 2230 ms.
tenary: 2250 ms.
which corresponds to a 25% improvement on the abstract equality case.
For regular code this will probably yield more performance, since we
get rid of the JSEqual operator, which might have arbitrary side
effects and thus blocks all kinds of TurboFan optimizations. The
JSStrictEqual case is slightly slower now, since it has to rule out
booleans as well (even though that's not strictly necessary, but
consistency is key here).
This way developers can safely use `a == b` instead of doing a dance
like `a == null ? b == null : a === b` (which is what dart2js does
right now) when both `a` and `b` are known to be Receiver, Null or
Undefined. The abstract equality is not only faster to parse than
the tenary, but also generates a shorter bytecode sequence. In the
test case referenced in http://crbug.com/v8/8356 the bytecode for
`naive` is
```
StackCheck
Ldar a1
TestEqual a0, [0]
JumpIfFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 14 bytes, whereas the `tenary` function generates
```
StackCheck
Ldar a0
TestUndetectable
JumpIfFalse [7]
Ldar a1
TestUndetectable
Jump [7]
Ldar a1
TestEqualStrict a0, [0]
JumpIfToBooleanFalse [5]
LdaSmi [1]
Return
LdaSmi [2]
Return
```
which is 24 bytes. So the `naive` version is 40% smaller and requires
fewer bytecode dispatches.
Bug: chromium:898455, v8:8356
Change-Id: If3961b2518b4438700706b3bd6071d546305e233
Reviewed-on: https://chromium-review.googlesource.com/c/1297315
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56948}
Also use low experiment percentage on CQ, since the builder's output is unused.
NOTRY=true
TBR=sergiyb@chromium.org
Bug: chromium:830557
Change-Id: Id024ab16e2944ec5e94b0209672ed6b77ae322a8
Reviewed-on: https://chromium-review.googlesource.com/c/1296466
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56947}
This is a reland of ec969ea3b1
Temporarily removes high memory usage test.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}
Bug: chromium:897404
Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223
Reviewed-on: https://chromium-review.googlesource.com/c/1297675
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56946}
Previously StringToList use the length of the original string, which is
not the right value: we expect the length of the new array to be the
number of characters (codepoints).
Bug: v8:7980
Change-Id: I2efca5715323c4399cb45c53871ae349207f3458
Reviewed-on: https://chromium-review.googlesource.com/c/1297320
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56944}
This additionally optimizes ExpressionListToExpression in the parser to
allocate Nary if possible. This allows us to drop unnecessary intermediate
objects in the parser, and avoids all the work altogether in the preparser.
Change-Id: I4a7d0ec3a28624c94ed85959d291e54eb81ffce3
Reviewed-on: https://chromium-review.googlesource.com/c/1297952
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56943}
For implementing wasm GC we need to revisit all places where we hold
WasmCode*. This CL reduces these places.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I869e3c1817a3b9a24ab6aa281c0688bdf890dd33
Reviewed-on: https://chromium-review.googlesource.com/c/1297951
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56942}
This CL introduces a ScopedPtrList that's a view over an underlying ZonePtrList
buffer. Whenever a ScopedPtrList is the top-of-stack list, you can add values
through it, which will add them to the end of the buffer. Once the list is
done, you can copy out the values to a real ZonePtrList. That way you do not
need to guess what the required size of the list is, and you get better cache
locality.
Change-Id: I2d229d73bb25bbb450ae5b6767ab100abad2b3a3
Reviewed-on: https://chromium-review.googlesource.com/c/1296458
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56939}
Because of ordering issues we didn't set the wire bytes on the
{NativeModule} during {OnFinishedStream}. We then failed during
instantiation when trying to read the import names from the wire bytes.
This CL fixes this locally without much code churn. I plan to clean up
the interaction between {AsyncCompileJob} and {AsyncStreamingProcessor}
in a follow-up CL.
R=ahaas@chromium.org
Bug: chromium:898310
Change-Id: I06337a04ba380f87b803f325323208298d363f41
Reviewed-on: https://chromium-review.googlesource.com/c/1296467
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56938}
In order to not confuse this with wasm memory.
R=mstarzinger@chromium.org
Bug: v8:8238
Change-Id: Ife183162a902ab1d141f6af95a9fa487a52379a1
Reviewed-on: https://chromium-review.googlesource.com/c/1296483
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56936}
