Port d303f4fba9
Original Commit Message:
In the past we've used the isolate argument to signal whether we were
in unicode mode (nullptr) or not (the real isolate). This is no longer
needed, and in fact breaks no-i18n mode which always expects to have a
real isolate.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2b8ede3c89738a6cec59f8e32657a3c8c815fe6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081888
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66534}
Stack parameters in the StubCallDescriptor were set to the wrong type. I
changed it now so that for stack parameters that are specified in the
CallInterfaceDescriptor, type specified type is used. All other
parameters are assumed to be tagged, as it has been until now.
Original change's description:
> [wasm] Refactor AtomicWait implementation
>
> The existing implementation included aspects that are not
> straight-forward to implement in Liftoff and seemed inefficient:
> * Convert the timeout in WebAssembly code from I64 to F64, just to
> convert it back in the runtime.
> * On 32-bit platforms this conversion needs an additional C-call.
> * Split the I64 expected value from I64 into two I32 values in the
> wasm-compiler.
> * Ideally the int64-lowering takes care of 32-bit specific handling.
>
> With this CL the timeout and the expected value are passed as I64 to
> the runtime (a builtin moves the I64 into a bigint for that). The
> int64-lowering takes care of 32-bit platforms. There are special
> builtins for 32-bit platforms, but they are written such that ideally
> also the int64-lowering could create them.
Bug: v8:10108
Change-Id: Ib87b543666708457c0d686208a86e46cdca3f9a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080362
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66533}
The frame created by the WasmDebugBreak builtin now has a separate frame
type, which will (later) allow to inspect the spilled registers.
Once Liftoff supports reference types, this frame will also need special
GC support for spilled heap references.
R=jkummerow@chromium.org
Bug: v8:10222
Change-Id: I110e51d1e6d09b0f44dcdd1cdcaafa2eaa64fddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083013
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66531}
Use macros to unify how HashTable (and subclasses) are marked as
externally specialised, and how those specialisations are initialised.
This cleanup will make it easier in the future to also add
specialisations of HashTable methods for Isolate/OffThreadIsolate.
Bug: chromium:1011762
Change-Id: Ibb62cf30d3ba40170e1d35ab72ada0f74963a5c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083023
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66528}
This reverts commit c6c9d4bf1b.
Reason for revert: Fails on noi18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/30737
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
TBR=jkummerow@chromium.org,jgruber@chromium.org
Change-Id: I960b90fe3679ef4c04782ca9ac9b91454e636dbb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083024
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66525}
There appear to be one or several bugs in noi18n mode such that
expectations in this test are no longer met. This CL updates
expectations to the current behavior and re-enables the test so we at
least preserve coverage in the other cases.
The behavior in question should be investigated in the future
(low priority).
Bug: v8:10120
Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66524}
Remove some duplication and make it easier to type a specific operation
with given input types.
Change-Id: I70d0424a1d1bd6330aa381568728d8313d5ad25d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078541
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66522}
Enable ArrayBufferExtensions by default. The
last CL (https://crrev.com/c/2078585) that tried to enable this was
reverted because of a TSAN failure. This was fixed in
https://crrev.com/c/2078586.
Bug: v8:10064
Change-Id: I2c3e0f2614323ea1521f2085b3c2bda5b69418ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083012
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66521}
In the past we've used the isolate argument to signal whether we were
in unicode mode (nullptr) or not (the real isolate). This is no longer
needed, and in fact breaks no-i18n mode which always expects to have a
real isolate.
Bug: v8:10120
Change-Id: I2f848c4ff8c2ff0e9b84278cbcdf3c3670e44e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081816
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66520}
This add StackArgumentsAccessor class to ia32, which slighty increases
abstraction when accessing arguments in the stack.
Bug: v8:10201
Change-Id: I4ee0323022d9334cb0b2af63a9c1f437eed9a079
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2073762
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66518}
This fixes a build break in certain configurations. v8_debug_helper
depends on generate_bytecode_builtins_list via the following headers:
In file included from gen/v8/tools/debug_helper/heap-constants-gen.cc:5:
In file included from ../../v8\src/common/ptr-compr-inl.h:10:
In file included from ../../v8\src/execution/isolate.h:19:
In file included from ../../v8\src/builtins/builtins.h:9:
Change-Id: I38e5d851afc6ce52716d3e5e64ae9219df396bd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078768
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66517}
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and
make the OffThreadIsolate allocate "real" Handles. Rather than using
the main-thread Isolate's handle scopes, these off-thread Handles are
backed by a Zone, which is tied to the lifetime of the nearest
OffThreadHandleScope. Eventually, we'll likely want to merge the
implementation of OffThreadHandleScope and HandleScope, but currently
the latter is too tightly coupled to the main thread to do so.
Bug: chromium:1011762
Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66516}
The JSArrayBuffer::extension-field might not be aligned with pointer
compression enabled. However on AArch64 pointers need to be aligned if
you perform atomic operations on them. Therefore split extension into
two 32-bit words that each get updated atomically. There is no ABA
problem here since the extension field only transitions from
NULL --> value --> NULL. After Detach(), Attach() isn't invoked anymore.
Bug: v8:10064
Change-Id: I20c1a37ac35d1749a94bfd277a4f91d531015bc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078586
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66515}
We can make better inlining decisions in TurboFan if the CallIC will
provide the feedback that it's seen multiple closures that share the
same SharedFunctionInfo. This is not difficult to do, and it fixes
some frustrating performance cliffs.
Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his
project a year ago.
Bug: v8:2206, v8:10100
Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66512}
This reverts commit 9325397812.
Reason for revert: Causing blink layout failures. See
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Future/2684
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
TBR=verwaest@chromium.org,timothygu@chromium.org,syg@chromium.org
Change-Id: I81737750f8b369567ba586c5a2cfb489836b7e74
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10200
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081091
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66510}
When a microtask is executed, we need to use an appropriate,
non-detached Context for its execution. Currently with
PromiseResolveThenableJobs [1], the Context used is always drawn from
the realm of the Promise constructor being used. This may cause
non-intuitive behavior, such as in the following case:
const DeadPromise = iframe.contentWindow.Promise;
const p = DeadPromise.resolve({
then() {
return { success: true };
}
});
p.then(result => { console.log(result); });
// Some time later, but synchronously...
iframe.src = "http://example.com"; // navigate away.
// DeadPromise's Context is detached state now.
// p never gets resolved, and its reaction handler never gets called.
To fix this behavior, when PromiseResolveThenableJob is being queued up,
the `then` method of the thenable should be used to determine the
context of the resultant microtask. Doing so aligns with Firefox, and
also with the latest HTML spec [2][3].
This change is analogous to CL 1465902, which uses the realm of the
reaction handlers to determine the Context PromiseReactionJobs run in.
[1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
[2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
[3]: https://github.com/whatwg/html/pull/5212
Bug: v8:10200
Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66507}
We need to track misc features launched in 2019 to understand the impact.
Also we need to measure the v8BreakIterator usage of 'word' and 'line'
to lobby the need for 'line' in the replacement standard Intl.Segmenter
which an Apple engineer opposed to include.
Bug: v8:10251
Change-Id: I5d4cbe6ccf458c9ec4adfebad235f9c6dcd2ac37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067512
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66506}
Previously, our Torque definition of JSArrayBuffer included only the
first two fields. This allowed access to those two fields, but was
somewhat confusing and obviously didn't let Torque code access the
other fields. This change:
- Completes the JSArrayBuffer layout definition;
- Moves the associated bitfield struct definition to Torque;
- Moves a couple of JSArrayBuffer macros to Torque;
- Adds a reducer case so that the code generated using these new macros
is not worse than what was generated previously.
Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66503}
More instructions are being emitted with 242d58e
hence the offset needs to be updated.
Change-Id: I892920837ca7d785eb423503921ee39134be1c0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079156
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66502}
The ArchLookupSwitch implementation has been completely replaced by
ArchBinarySearchSwitch, leaving dead code behind.
Change-Id: I7fd6306cb0f5562c10e32293f5ea13bbd3bf7067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2077684
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66501}
This fixes a crash related to access after free on platforms that
store the MacroAssembler as a pointer. The intended behavior is
restored by explicitly setting the flag in the macro assembler
instead of using NoRootArrayScope.
Landing as TBR as it's blocking fuzzers and fix seems simple enough.
TBR=jgruber@chromium.orgR=jyan@ca.ibm.comR=miladfar@ca.ibm.com
Bug: chromium:1057018
Change-Id: Ib6de82b47bb1abb74da58b3d476b359669372bb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080242
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66500}
The interface for ArgumentInfo was allowing out-of-bounds
read from the returned array. Improved that by passing the
index explicitly as a parameter and checking against the
expected bounds.
Bug: v8:10267
Change-Id: Ic1022def3e338598cd9bd9e6582d67a62836d0db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078578
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66499}
This reverts commit 77d4e23047.
Reason for revert: verify csa build bot broken
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/16218?
Original change's description:
> [wasm] Refactor AtomicWait implementation
>
> The existing implementation included aspects that are not
> straight-forward to implement in Liftoff and seemed inefficient:
> * Convert the timeout in WebAssembly code from I64 to F64, just to
> convert it back in the runtime.
> * On 32-bit platforms this conversion needs an additional C-call.
> * Split the I64 expected value from I64 into two I32 values in the
> wasm-compiler.
> * Ideally the int64-lowering takes care of 32-bit specific handling.
>
> With this CL the timeout and the expected value are passed as I64 to
> the runtime (a builtin moves the I64 into a bigint for that). The
> int64-lowering takes care of 32-bit platforms. There are special
> builtins for 32-bit platforms, but they are written such that ideally
> also the int64-lowering could create them.
>
> R=jkummerow@chromium.org, binji@chromium.org
>
> Bug: v8:10108
> Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66497}
TBR=binji@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org
Change-Id: If284aa07eedddd2fbea4df8c53c7d371cac1d42e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080250
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66498}
The existing implementation included aspects that are not
straight-forward to implement in Liftoff and seemed inefficient:
* Convert the timeout in WebAssembly code from I64 to F64, just to
convert it back in the runtime.
* On 32-bit platforms this conversion needs an additional C-call.
* Split the I64 expected value from I64 into two I32 values in the
wasm-compiler.
* Ideally the int64-lowering takes care of 32-bit specific handling.
With this CL the timeout and the expected value are passed as I64 to
the runtime (a builtin moves the I64 into a bigint for that). The
int64-lowering takes care of 32-bit platforms. There are special
builtins for 32-bit platforms, but they are written such that ideally
also the int64-lowering could create them.
R=jkummerow@chromium.org, binji@chromium.org
Bug: v8:10108
Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66497}
There were a few places that still checked against the limit for
initial memory size rather than the limit for memory size after
growth (which was recently separated from the former).
Bug: v8:7881
Change-Id: Id17d86e2f7a5dfa4f1dd35153b0cefc01f72ed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078574
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66496}
Port 6cd28b522a
Original Commit Message:
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
compilation by using alternative temp register for x64.
macro assemblers.
R=ecmziegler@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib08e31dfa11f0254c7888ce17dd27e7d0154c752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078898
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66490}
The set of isolates known to a native module and the set of native
modules known to an isolate were not updated on cache hit. This caused
the wasm engine to collect code when it was still live in some isolate.
R=clemensb@chromium.org
Bug: chromium:1055131
Change-Id: I56682509b284c9c0dce7c95ee20ec3929e2e8c9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078583
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66488}
This reverts commit 4c7c6f732c.
Reason for revert: Reverted because of TSAN failures.
Original change's description:
> [heap] Enable usage of ArrayBufferExtensions
>
> Switch the flag to true to enable ArrayBufferExtensions by default. The
> last CL (https://crrev.com/c/2065088) that tried to enable this was
> reverted because of alignment issues on ARM64
> (fixed in https://crrev.com/c/2071256).
>
> Bug: v8:10064
> Change-Id: I47f478c978094fb5038113eb452865748956b42e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074157
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66460}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10064
Change-Id: Ie15bf9858eb1f01667ea905363824cbb2bf7f884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078585
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66487}
This reverts commit 1f35c16553.
Reason for revert: speculative revert for TSAN failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12179
Original change's description:
> [objects] Update JSArrayBuffer::extension-field in two steps
>
> The JSArrayBuffer::extension-field might not be aligned with pointer
> compression enabled. However on AArch64 pointers need to be aligned if
> you perform atomic operations on them. Therefore split extension into
> two 32-bit words that each get updated atomically. There is no ABA
> problem here since the extension field only transitions from
> NULL --> value --> NULL. After Detach(), Attach() isn't invoked anymore.
>
> Bug: v8:10064
> Change-Id: If987ed51f0528ca7313980f3d36ffca300b75fdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071256
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66457}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10064
Change-Id: I2107a4d49d2b127dc65ce11b3b61ccc592fb0736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078579
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66485}
