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}
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}
Computing on-the-fly whether blocks are deferred is a bit tricky,
because some optimizations (BranchElimination and
MachineOperationReducer in particular) can remove branches, resulting
in deferred blocks with non-deferred predecessors and successors.
We are thus opting for the simpler solution: having branch hints on
branches, so that eliminating branches of cloning blocks doesn't have
an impact on deferredness.
Fixed: chromium:1393733
Bug: v8:12783
Change-Id: Ic886f48a33f25f1a3068b9bf684fae43e1f53b6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061266
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84558}
Operation was already implemented in crrev.com/c/3945132.
This CL adds it under AssembleArchBoolean as well as FlagsConditionToCondition.
Change-Id: I24b56dd6f3cabccefb5fdc0d699c78a960f97fb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062268
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84557}
GlobalSafepointScope may be nested similar to isolate-local
SafepointScopes.
Bug: v8:13267, v8:13539
Change-Id: Ic2709a6466a42160d2a2c392fdf9521432725604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062090
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84556}
When generational GC is enabled, some objects may already be allocated.
However, the age table entries corresponding to them would not be
marked, which would break marking verifier. The CL fixes it by
explicitly marking all entries as young.
Bug: v8:13475
Change-Id: I5b4206c0c978f0486e85c6c02a6c76b59152d7bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061731
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84554}
Disable incremental marking for the tests to make sure that the
generational barrier always fires.
Original change's description:
> unified-young-gen: Implement generational barrier for TracedHandles
>
> If unified young generation is enabled, we don't record all young nodes,
> but only ones that have old host. The same std::vector<TracedHandle*> is
> reused for the remembered set implementation.
>
> The barrier is added to TracedHandle creation, i.e.
> - v8::TracedReference::Reset(),
> - v8::TracedReference::operator=(const TracedReference&),
> and to moving between TracedHandles, i.e.
> - v8::TracedReference::operator=(TracedReference&&).
>
> Bug: v8:13475
> Change-Id: I2dc236e21c05f797687344c5745896f0bb8b0a0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4057070
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84513}
Bug: v8:13475
Change-Id: I329a0b52e1fb7a24abc130c6bc493ad1b1ccbfee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062040
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84553}
