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}
This CL adds one byte string specialization support for fast API call arguments.
It introduces a kOneByteString variant to CTypeInfo.
We see a ~6x improvement in Deno's TextEncoder#encode microbenchmark.
Rendered results: https://divy-v8-patches.deno.dev/
Bug: chromium:1052746
Change-Id: I47c3a9e101cd18ddc6ad58f627db3a34231b60f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4036884
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84552}
Make the setup_isolate_delegate stateless. It does not make sense to
pass a setup delegate to Isolate::Init that would contradict the
configuration of the isolate, hence it does not make sense to let the
delegate decide if heap objects should be created. Instead let the
isolate decide on how to invoke the delegate.
Cleanup in preparation for later changes to mksnapshot.
Bug: v8:13466
Change-Id: I5ca36a1db3e94baf068ba0dc91729a78086a023c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020172
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84550}
Passing a {unique_ptr} plus the size of the array separately makes it
easier to pass non-matching values. Using {base::OwnedVector} instead
makes all call sites cleaner.
R=ahaas@chromium.org
Change-Id: I66cf8e756d098837aac71e410b18e08646e512b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061893
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84549}
There are other wrapper types that may coalesce to the same visitor id.
The CL simply checks that the objects being visited have embedder
fields.
Bug: v8:13475
Change-Id: I098056e9cf720ac0d5c6b10495ccdca88df62ecf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061575
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84548}
For performance profiling in DevTools, LogWasmCode has to be called on
every isolate for a NativeModule. After receiving a NativeModule from
postMessage, the call to LogWasmCode was missing.
R=clemensb@chromium.org
Bug: chromium:1381182
Change-Id: Ibbb5129a848477c42ac2a8fbc04b0e61ec8900eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051245
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84546}
The AssertNotNull operator can be used to represent a trivial type
cast. Therefore it needs to take the trap id as a parameter.
We also use this operator in one more place in
{graph-builder-interface}.
Bug: v8:7748
Change-Id: I679c996ef07063c03e1103acac1db91184b15c0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061514
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84543}
As {Result<T>} encapsulates a value of type {T} (or an error), it should
be implicitly convertible to {Result<U>} if {T} implicitly converts to
{U}.
We only define that implicit conversion for r-value references, so it
can only be used when "copying" a result value (i.e. passing by value or
returning from a function).
This avoids two nasty explicit template declarations in the module
decoder.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I6d730de236502f83b9924cacd3693753d6109996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062086
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84542}
This CL moves the V8_ENABLE_FORCE_SLOW_PATH-dependent checks from C++
code to CSA graph in order to ensure that the builtins control flow
structure is V8_ENABLE_FORCE_SLOW_PATH-independent.
Since the constant value is known at compile-time TurboFan will remove
the check and delete the dead code so in the end the generated code
will be the same and when the check was on C++ side.
However, having these checks in the CSA graph keeps the initial state
of graph structure the same regardless of the V8_ENABLE_FORCE_SLOW_PATH
value which in turn makes the builtins PGO profiles reusable.
Bug: v8:10470
Change-Id: Ia0ddd1c099c5093a09904a8dd3aef748e0925540
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061891
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84541}
{console.log} messages from tests can currently be buffered, which makes
it impossible to use them for seeing how long certain code executes.
R=ahaas@chromium.org
Change-Id: I785f7809c0bd837074a1c8a03465111a744e4d87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061729
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84539}
We currently add two samples: One for the overall wire bytes size and
one for the number of declared functions. Both is not only available
during decoding, but also to the caller. Hence separate the update of
counters and events from actual decoding. This will make it simpler to
decode a module (for re-validation) without updating counters.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Ib00f4150cf2ad5452090f0aff8198b31d075b49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061687
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84538}
Currently, the ScopeIterator uses the re-parsed lexical scope info to
write to, and read from contexts. This assumes that we always manage
to match the re-parsed scope chain with the context chain on a pause.
Unfortunately there are rare edge cases where we have a miss match.
This CL adds a check that makes sure that a Context's ScopeInfo knows
about the variables we actually want to read/write and don't rely
solely on the AST. Once the bug is fixed, we can turn this into a
CHECK instead.
R=jarin@chormium.org
Bug: chromium:753338
Change-Id: Iefe1fdc025dcb570fc98167134e230b204d595b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061077
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84537}
This reverts commit e31a7192ee.
Reason for revert: TSAN failure for the newly added unittest: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/10056/overview
Original change's description:
> Reland "unified-young-gen: Implement generational barrier for TracedHandles"
>
> The dcheck was fixed in 7b40cb0c1b. The MSVC was also fixed.
>
> 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: I8ecde011af077a818b7b96af57e15b607febb185
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061693
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84533}
Bug: v8:13475
Change-Id: I05a179a5ef79890640bba450c4f3e3178c38228f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061464
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84536}
