- Adds code gen prologue
- Adds a few essential nodes in arm64
- Shares a few non-arch dependent nodes w/ x64
- Shares deferred code handling, deopting and vreg helpers w/ x64
Caveats:
- Deopts don't work, since CallForDeoptimization in arm64 uses a
different mechanism (not yet implemented).
- ParallelMoveResolver and ExceptionHandlerTrampolineBuilder uses
singles push/pop mechanism, which is not arm64 friendly. We add
a padding for each push/pop at the moment.
Bug: v8:7700
Change-Id: I2896f3cd272fc47d7bd9059c8cc8948221b3b932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069708
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84607}
Rolling v8/build: 73d7c51..961774e
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1d3369c..550c7af
Rolling v8/third_party/depot_tools: 391cc61..c4044d4
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221130.0.1..version:10.20221201.2.1
Rolling v8/tools/clang: 1b8faee..83f8830
Rolling v8/tools/luci-go: git_revision:7a04ca7c0fd3e73cc09c817542a74d947e68b8c9..git_revision:4814885a05fd7cc925933f614dc6fcc58bc83e4b
Rolling v8/tools/luci-go: git_revision:7a04ca7c0fd3e73cc09c817542a74d947e68b8c9..git_revision:4814885a05fd7cc925933f614dc6fcc58bc83e4b
Change-Id: I33712632cec3bfaf416e4e8cf0b2ca08a65fb1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075044
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84606}
This is a reland of commit 48a6193e67.
PS2 fixes the use-after-free by using the WasmEngine's allocator instead
of the Isolate's. The module can live longer than the isolate, so on
module destruction we would otherwise potentially access an already
deleted allocator.
Original change's description:
> [wasm] Remove StartDecoding method
>
> Move it into the constructor instead, to simplify the API.
>
> R=ahaas@chromium.org
>
> Bug: v8:13447
> Change-Id: I563a409c57c3cfdd91998c7c459f4e099211ccf7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062042
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84589}
Bug: v8:13447
Change-Id: I33c3c641ab6de6b6e30365fe967a579469039740
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4070264
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84604}
This is split out from
https://chromium-review.googlesource.com/c/v8/v8/+/3963708, and
implements only the change to using a dispatcher code stub for different
object types in GetOwnPropertyDescriptor, which returns a
PropertyDescriptor struct, and converts the descriptor into a JSObject
in the final step of Reflect.getOwnPropertyDescriptor or
Object.getOwnPropertyDescriptor.
This does not include the path in the dispatcher for Proxy objects, and
thus Proxy objects are still handled in the runtime.
Change-Id: I3960615aa0941d02d32717ccea291f6b63ae180e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4024866
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84602}
... to match new encoding of the forwarding pointers.
Bug: v8:11880, chromium:1393256
Change-Id: I8bc8183c22ef8933c02470d5c8ed77cf83489e0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069706
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84601}
In case of nested GCs, NotifyFullSweepingCompleted will first notify
that the nested young cycle is finished, which in turn will check
whether we need stop the full cycle as well.
After returning from NotifyYoungSweepingCompleted,
NotifyFullSweepingCompleted tries to stop the full cycle again, which
triggers the DCHECK that the current cycle is in a sweeping state.
Bug: v8:12612
Change-Id: I659038c04533b71bbc379cd51d22441e44e96021
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069707
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84600}
A gn build with no specified targets builds all visible targets. The
postmortem-metadata action is visible, but its output is only needed
if v8_postmortem_support is enabled, hence we now guard the whole
action by the flag.
Depends on https://crrev.com/c/4064686
Bug: chromium:1394626
Change-Id: I8444021cfe253cedee5c1578c733a3ad973726db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061865
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84599}
Adds new `br_on_cast <branch depth> <heap type>` instruction
with opcode 0xfb42.
The instruction does not branch on null.
The heap type may be any concreate heap type index or an abstract
type like `(ref null eq)`.
Bug: v8:7748
Change-Id: Id1d238645c176b32b568249d67fa28517b435ad4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4069559
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84598}
This CL fixed missing instance type checks for constant shift
amounts and corrected the use info for the lhs.
Bug: chromium:1393865, v8:9407
Change-Id: Id6e65f4e26a0436960b12196f29663429876398b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061075
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84596}
This is a reland of commit 3a946583e2
The issue was in a Chromium test which was fixed here:
https://crrev.com/c/4061562
Original change's description:
> [sparkplug] Enable concurrent Sparkplug on desktop
>
> Bug: v8:12054
> Change-Id: Iffeedc6d33483d86d95169aaf45c214e32c8bc83
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061312
> Auto-Submit: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84531}
Bug: v8:12054
Change-Id: I77399aca2945a4a0f64a533ca72b1d629c591f96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4064462
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84595}
An {OwnedVector} that was moved or assigned to another {OwnedVector} was
left in an inconsistent state: {data_} was null, but {length_} was
non-zero.
This CL changes that to leave the moved-from vector in a valid (empty)
state, similar to what the {std::vector} move constructor and assignment
does.
R=mlippautz@chromium.org
Change-Id: I59b543b2cea4bc0e066b7817cee1de6b2b8a7735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84594}
When importing a WasmExportedFunction into a module, we checked that
its type is equivalent with the declared type of the import. Instead,
we should check that the imported function has an isorecursive subtype
of the declared type.
Change-Id: I2a5f68d4c4c8c65a0eed5b82e8e825affb832cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061732
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84593}
With v8_use_perfetto = true, tracing sessions are controlled by
Perfetto, not TraceLog. This can lead to inconsistencies, e.g.
TraceLog signalling trace start while V8's TrackEvent datasource
hasn't been initialized yet.
This CL removes the TraceStateObserver interface and replaces its
uses with perfetto::TrackEventSessionObserver which correctly tracks
Perfetto tracing sessions start and end.
See also crrev.com/c/4066184 for the corresponding Chrome change.
Bug: chromium:1006766
Change-Id: I94b2189c8b28aec8b17ec8fc1246e27c904e4ee9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062038
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#84590}
Move it into the constructor instead, to simplify the API.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I563a409c57c3cfdd91998c7c459f4e099211ccf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062042
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84589}
Instead of using IsWindows8Point1OrGreater which only works if the
application is manifested for Windows 8.1 or Windows 10, now query the
size of the virtual address space using GetSystemInfo (on Windows) or
getrlimit (on Linux).
Bug: v8:10391
Change-Id: If2322dbd82954640feb33c3cf93dde455038ec67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4040664
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84588}
This reverts commit 4588fe544f.
Reason for revert: Fails on MSVC Windows builds: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc%20-%20builder/4779/overview
Original change's description:
> adds the ability for v8 to use sin/cos from libm
>
> This is controlled by a gn arg, which defaults to true for clang
> builds. I'm limiting to clang builds as the macros for determining
> endian type are currently clang specific. My understanding is that
> chrome only uses clang. I can update the endian macros if necessary
> for other targets.
>
> Bug=v8:13477
>
> Change-Id: I604f99a2464b1d57f792bb339f9240ef043251e7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000442
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Commit-Queue: Scott Violet <sky@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84577}
Change-Id: I96a1571196fe658568c626e5d36559e496ba4d45
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067303
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84586}
This is a reland of commit 8016f5c667
Additional HandleScopes are added in 3 spots and an additional
test was added to cover the crash that caused the revert.
Adding and removing the MicrotasksCompletedCallback should be
associated with the microtask queue of the Context. We store the
context as WeakPtr and always remove the callback when it completes
regardless of the state of the debugger.
BUG=v8:13450
Change-Id: Ie4d6edcb561c6753a6d34d84cfcf4989bb6e9321
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062397
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84584}
Rolling v8/build: f27bbaf..73d7c51
Rolling v8/buildtools: 531b10a..8d4ff27
Rolling v8/buildtools/third_party/libc++/trunk: 325733d..ae1fbc4
Rolling v8/buildtools/third_party/libc++abi/trunk: 9231726..44d54ba
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4431cae..1d3369c
Rolling v8/third_party/depot_tools: 141be0c..391cc61
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221129.1.1..version:10.20221130.0.1
Change-Id: Ibd56ce1d3746cf927f61820ada5ee95e34dbe2a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068005
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84583}
Array.of/from returned HOLEY elements kind even though their returned array can be PACKED, which made it hard to take fast paths for PACKED arrays.
This CL creates a PACKED array directly for the cases where the receiver is the default array function.
Bug: chromium:1305342
Change-Id: Id14124d029ea87dc7c9320f62087f63460acd446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062669
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84582}
The fuzzer had some issues with the initial CPU profiling code:
* The CpuProfiler may get accessed from multiple workers/isolate/threads,
which caused a use-after-free if the CpuProfiler gets disposed while
some thread is still accessing it.
* and profiling may not have been stopped before disposing the profiler,
which caused a use-after-free by the profiling thread which did not get
stopped.
The first issue was caused by storing a global `CpuProfiler*` in d8,
which was shared among all threads. This pointer was needed to call
`CollectSample`. The solution was to load the D8Console from the isolate,
and then load the `CpuProfiler*` from the D8Console. Thereby a thread
always loads a thread-local `CpuProfiler*`, which is then guaranteed to
exist.
The second issue was solved by calling `StopProfiler` before `Dispose`
if profiling was still ongoing.
R=clemensb@chromium.org
Bug: chromium:1394581
Change-Id: Ia17809c7b1a3d72d9da919db5c3d3d5f200c0747
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4065680
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84581}
Array.reverse was optimized only for PACKED_* arrays. This CL adds fast paths for HOLEY_* arrays as well.
Bug: chromium:1305342
Change-Id: I83c5ffa6e823478992c2caabd9a88d405b35e464
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062673
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84580}
This was written in a single statement:
state_out->set(to_index, GetMoveSource(state_out, move));
which is unsafe, because it combines a Handle dereference, and a
potentially GC-triggering call (GetMoveSource).
By splitting the statement in two, the Handle is guaranteed to be
dereferenced after the potential GC.
R=dmercadier@chromium.org
Bug: v8:13544
Change-Id: I9645dabf602c16872356c225ad7f383ab7e457d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066541
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84579}
This is controlled by a gn arg, which defaults to true for clang
builds. I'm limiting to clang builds as the macros for determining
endian type are currently clang specific. My understanding is that
chrome only uses clang. I can update the endian macros if necessary
for other targets.
Bug=v8:13477
Change-Id: I604f99a2464b1d57f792bb339f9240ef043251e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000442
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84577}
If we'd do it before merging register values, we might drop a value from
a register that's needed by a phi.
Bug: v8:7700, chromium:1394036
Change-Id: I39be09d5ccf19ff70aaefc8865565f0d2169552c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4063692
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84576}
Due to mismatch in strictness we otherwise invalidly mark scopes as
calling sloppy eval.
Bug: chromium:1394403
Change-Id: Iece45df87f171616a2917c2aba5540636880a7c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066044
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84575}
This is a reland of commit 5dbba8b007
Excluding ICU from UBSAN as there are new failures reported, until they are addressed in bug chromium:1394654.
Bug: chromium:1394654
Original change's description:
> Update V8 DEPS (trusted)
>
> Rolling v8/build: 0efbd89..f27bbaf
>
> Rolling v8/buildtools: f2fe6dd..531b10a
>
> Rolling v8/buildtools/linux64: git_revision:1c4151ff5c1d6fbf7fa800b8d4bb34d3abc03a41..git_revision:70d6c60823c0233a0f35eccc25b2b640d2980bdc
>
> Rolling v8/buildtools/third_party/libc++/trunk: c2e1032..325733d
>
> Rolling v8/buildtools/third_party/libc++abi/trunk: 7362046..9231726
>
> Rolling v8/buildtools/third_party/libunwind/trunk: 5870472..fd49ee4
>
> Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/41982a4..4431cae
>
> Rolling v8/third_party/depot_tools: 9a6aa08..141be0c
>
> Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221128.1.1..version:10.20221129.1.1
>
> Rolling v8/tools/clang: 6846e1e..1b8faee
>
> Rolling v8/tools/luci-go: git_revision:f8f64a8c560d2bf68a3ad1137979d17cffb36d30..git_revision:7a04ca7c0fd3e73cc09c817542a74d947e68b8c9
>
> Rolling v8/tools/luci-go: git_revision:f8f64a8c560d2bf68a3ad1137979d17cffb36d30..git_revision:7a04ca7c0fd3e73cc09c817542a74d947e68b8c9
>
> Change-Id: I3d89ad61526c3288c7788480c1355d94ad39fb1e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4063722
> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
> Cr-Commit-Position: refs/heads/main@{#84559}
Change-Id: Ifa89aa3e1e7cc69a6afd72c161027e5874d3c541
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067041
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84574}
In case of empty arguments, we set the receiver_mode to
kNullOrUndefined, which forces the new receiver to be null.
But now `args` has a null receiver and 1 non-receiver argument.
We *must* clear the argument vector to avoid using the old receiver as
the first argument to FunctionPrototypeCall.
Bug: v8:7700
Change-Id: Ie23bfb28a50f484fbdd6caba55b44ffbaa806b34
Fixed: v8:13456
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066479
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84571}
This ensures that V8_EXPORT lines generated by
gen-postmortem-metadata.py have a deterministic order (the original
order) while removing duplicates.
Bug: chromium:1394626
Change-Id: I6d634962ed9f9f97c2b0dfa3b6d9c32b5894df54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061864
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84568}
If we have many maps to check, we cannot guarantee that the jump
offset fits in an int8.
Bug: v8:7700
Fixed: chromium:1393940
Change-Id: I7cf47bbea4ceaf4f3113aeb9e2de0c0e0bb90baa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4065879
Commit-Queue: Leszek Swirski <leszeks@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/main@{#84567}
The main thread can enter TransitionsAccessor::PutPrototypeTransition,
lock the full_transition_array_access mutex, and then try to allocate,
which can trigger a GC. It would then wait for all threads to be in a
Safepoint.
However, if a background thread tried to acquired a shared lock on
full_transition_array_access (this happens from
JsNativeContextSpecialization::ReducePropertyAccess, which eventually
calls TransitionsAccessor::SearchTransition, which takes tries to take
the shared lock) outside of a safepoint, we have a deadlock: the main
thread waits for the background thread to be in a safepoint, but the
background thread waits for the main thread to release the lock on
full_transition_array_access.
This CL fixes the issue by releasing the shared lock from the main
thread during the "allocation" part of the growing of the transition
array, so that the background thread can take the shared lock and then
reach a safepoint; the main thread would then do the allocation and
trigger the GC, and only then take the exclusive lock to replace the
old transition array by the new one (but this wouldn't allocate).
Bug: chromium:1393904
Change-Id: Ia3b94be575a0266c41c2fe6445090e551673b617
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062039
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84565}
Profiles for 64/32 bits architectures are not interchangeable but
profiles collected for x64/x86 can be used for arm64/arm respectively.
Attempt to use an incompatible profile is now a fatal build error.
Note that some Float64RoundXXX instructions that are available on
arm64 are not available on x64, so we generate a bunch of code
containing branches instead. This means that we are safe to use x64
profiles for arm64 but not the other way round, otherwise we'll miss
the profile info for the subgraph that's not generated on arm64.
Bug: v8:10470
Change-Id: I6a34836866363207b5ed767e343100b406ac7990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055274
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84564}
This is a straight copy of the appropriate files. They are not
compiled yet. I'm separating out the two patches so that it's easy
to see what changed.
Bug=v8:13477
Change-Id: I2177cc08ff3a74cc7be70bb5ca9c981c0c316814
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4006234
Auto-Submit: Scott Violet <sky@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84563}
StubCaches contain keys (internalized strings), which are stored in
shared space if the string table is shared.
After a GC, StubCaches are simply cleared to not contain pointers to
invalid objects (e.g a key was evacuated).
This CL clears the StubCaches also for shared GCs, as keys might not be
valid afterwards.
Clearing the caches is now done in GC directly instead of invoking
Callbacks. First, GC callbacks are not supported for shared GCs (and it
is preferred to not support them) and second, this way it is guaranteed
that the caches are cleared before any other callback might access the
stub caches.
Bug: v8:13537
Change-Id: I8c9782596e4a208b07a7273ebc59544f8095474f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4064259
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84562}
