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}
Recently the callstats runner started crashing due to scipy imports.
This CL moves the import to mitigate the crashes.
TBR=machenbach@chromium.org
Bug: v8:10269
Change-Id: I67c2093f12ae287354a59e9cd32b79c6288b8edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078571
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66483}
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.
Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.
Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.
R=clemensb@chromium.orgR=petermarshall@chromium.orgR=jgruber@chromium.org
Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
Most function signatures are created once and never changed. Hence pass
them as const pointer. This makes it clear in function signatures that
these parameters will not be modified.
This also avoids a few ugly const_casts where we were passing pointers
to constexpr FunctionSigs via non-const pointers.
R=jkummerow@chromium.org
Bug: v8:10155
Change-Id: Ieb658ab5582bff276f76babdaf7ddb8f72bd4790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072739
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66478}
This is a reland of 7d1f95d6e4
The reland fixes a performance issue in that we incorrectly marked
every pattern containing a backslash as needing to be escaped,
resulting in a new string allocation instead of reusing the existing
string.
Original change's description:
> [regexp] Correctly escape a backslash-newline sequence
>
> When printing the source string, a backslash-newline sequence ('\\\n',
> '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
> '\u2028', '\u2029', respectively. Prior to this CL it was formatted as
> a backslash followed by the literal newline character.
>
> Bug: v8:8615
> Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65986}
Bug: v8:8615,chromium:1046678
Change-Id: I5d75904f1ea543ec679649668e54749821116442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074159
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66476}
This allows Torque code to refer to these bitfields (not currently
relevant for any of these classes), and allows the postmortem debugging
API to provide details about these bitfields.
Change-Id: I79c74a3c5ef1f77e839720a4e8ee1f8482a576ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049870
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66471}
This adds static types to the argument class that accesss the arguments in the
stack. kRuntime arguments are used by runtime functions and kJS arguments
are used to access the JS stack (eg. builtins).
The distinction allows the reversal of arguments in the JS stack without
changing the runtime arguments order.
Bug: v8:10201
Change-Id: I7c08164d53c4071c7910836fa733dee8ff7fa680
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066985
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66470}
The method was deprecated in favor of {IsWasmModuleObject}.
R=adamk@chromium.org
Bug: v8:10155
Change-Id: Id21a1b74dde5576c2c82cc209555c22209a9e5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033170
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66469}
This is a reland of 0dc598df0c
Original change's description:
> [wasm] Refactor callback triggering
>
> 1) Instead of passing three boolean values to |TriggerCallbacks|, pass
> one EnumSet which contains all events to trigger.
> 2) Remember which events already happened, to avoid triggering them
> again.
> 3) Compute triggered events once after the loop in |OnFinishedUnits|,
> instead of checking for every finished unit.
> 4) When a new callback is registered, trigger all previous events
> immediately. This solves issue v8:10217.
> 5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
> 6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
> compiled (this is a minor performance optimization; we save taking
> and releasing a lock).
> 7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
> |Mask| constexpr).
>
> R=ahaas@chromium.org
>
> Bug: v8:10217
> Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66459}
Bug: v8:10217
Change-Id: I9f7ca424fa7f1d0379dabe230bebf62522dfc857
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074501
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66468}
It used to print the elements kind as a byte, thus producing \000 etc.
This also broke the json produced by --trace-turbo.
Change-Id: I2f9ce5cb5815ab30fd7866e52fa5ab2732904e1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074640
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66466}
This reverts commit 4dc1fb4e04.
Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea962e.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> > is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> > occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> > code for IncBlockCounter match with what was generated before this
> > change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> > API. The format matches existing bitfields but with an offset value
> > that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}
This is a first step to make {WasmCode} objects smaller. Many code
offsets are currently stored in {size_t} even though there were
originally (during assembly) an int. Others are stored in {uint32_t}.
This CL switches the function index and all code lengths and offsets to
int, because
a) bigger code is not supported anyway, and
b) the style guide recommends int over unsigned types.
This makes the {WasmCode} 24 bytes smaller on x64 (from 144 to 120
bytes).
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I8f78bf4be64d59cf9393e3b6662d9d3bd153d387
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074217
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66462}
This reverts commit 0dc598df0c.
Reason for revert: Fails the wasm-cache-test blink test.
Original change's description:
> [wasm] Refactor callback triggering
>
> 1) Instead of passing three boolean values to |TriggerCallbacks|, pass
> one EnumSet which contains all events to trigger.
> 2) Remember which events already happened, to avoid triggering them
> again.
> 3) Compute triggered events once after the loop in |OnFinishedUnits|,
> instead of checking for every finished unit.
> 4) When a new callback is registered, trigger all previous events
> immediately. This solves issue v8:10217.
> 5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
> 6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
> compiled (this is a minor performance optimization; we save taking
> and releasing a lock).
> 7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
> |Mask| constexpr).
>
> R=ahaas@chromium.org
>
> Bug: v8:10217
> Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66459}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I564b053e898db5f7b51cefa4626c0625a225c89a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10217
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074638
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66461}
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}
1) Instead of passing three boolean values to |TriggerCallbacks|, pass
one EnumSet which contains all events to trigger.
2) Remember which events already happened, to avoid triggering them
again.
3) Compute triggered events once after the loop in |OnFinishedUnits|,
instead of checking for every finished unit.
4) When a new callback is registered, trigger all previous events
immediately. This solves issue v8:10217.
5) Replace |NotifyTopTierReady| by |AddCallback| which is identical now.
6) Do not call |OnFinishedJSToWasmWrapperUnits| if no wrappers were
compiled (this is a minor performance optimization; we save taking
and releasing a lock).
7) Drive-by: Make the |EnumSet| constructor really constexpr (by making
|Mask| constexpr).
R=ahaas@chromium.org
Bug: v8:10217
Change-Id: Ib3688a1687ad7b523e90efd73f4073e9f1193016
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072737
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66459}
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}
When iterating objects on a page add CHECKs that we actually load a
map and ensure the object ends within the current chunk.
Bug: chromium:1055252
Change-Id: I8f2d5f08229cb1a2fce64af6e22988de87d1b572
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072744
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66456}
1) Merge |AddBaselineCompilationUnits| into
|InitializeRecompilationProgress|.
2) Rename |InitializeRecompilationProgress| to
|InitializeRecompilation|.
3) Unify the update of |ReachedRecompilationTierField| in
|compilation_progress_|.
R=ahaas@chromium.orgCC=duongn@microsoft.com
Bug: v8:9654
Change-Id: I58324b553bf226cacb355e387c235841fdea82d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071863
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66454}
