This reverts commit e7f6d34cfe.
Reason for revert: Regressions and clusterfuzz bugs
Original change's description:
> [ic] Remove SameValue optimisation for constant fields
>
> We would previously try to preserve field constness if field assignment
> was assigning the same value. It's unexpected that real-life code would
> be assigning the same value multiple times to an intentionally constant
> field, so this was additional bookkeeping with unclear value.
>
> Replace this with not doing it, and considering any write to a constant
> field to convert it to mutable. In particular, this means that stores to
> existing constant fields in TurboFan become unconditional deopts, rather
> than emitting additional code to check whether the value is the same.
>
> Locally, this deopt doesn't fire on our peak-performance benchmarks.
>
> Bug: v8:5495
> Change-Id: I12216c5f10a00f42be32c64ca3afe7cf59b4e7f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976516
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83955}
Bug: v8:5495
Change-Id: Ifeeceb773af04e9dd5e069821cd128a1cdbedcf5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990683
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83970}
The following bots were removed or renamed:
v8_fuchsia_compile_rel
v8_linux64_gcc_compile_rel
v8_win_compile_dbg
v8_win64_msvc_compile_rel
v8_mac_arm64_compile_rel
v8_mac_arm64_compile_dbg
v8_mac_arm64_sim_compile_rel
v8_mac_arm64_sim_compile_dbg
v8_mac64_asan_compile_rel
They are all auto-generated as compilators.
Bug: chromium:890222
Change-Id: I893eb06497084976ed0b162ea2e252419c0884b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3988264
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#83967}
Rolling v8/build: 4e03165..9ce69a9
Rolling v8/buildtools: ddc9513..c50c0de
Rolling v8/buildtools/linux64: git_revision:3e98c606ed0dff59fa461fbba4892c0b6de1966e..git_revision:11dc0b1f438bd26380774e9d50fd4c63f346d41a
Rolling v8/buildtools/third_party/libc++/trunk: baa43f8..47b3117
Rolling v8/buildtools/third_party/libc++abi/trunk: 519e9ef..c7b6fcf
Rolling v8/buildtools/third_party/libunwind/trunk: 1f633d4..aabcd87
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2f63d55..d2c6581
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221026.0.1..version:10.20221027.2.1
Rolling v8/third_party/instrumented_libraries: f764ffc..03ce9f0
Rolling v8/tools/clang: 87d0b8c..38497db
Change-Id: I2b6f402b468a5607b3cbb347f015ac7634a5492f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990203
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83965}
Tests flagged as 'raw' need to run without the harness. The language/module-code/eval-gtbndng-indirect-faux-assertion test was failing only because it was running with the harness.
Bug: v8:10958
Change-Id: If00f3ec8abc697d9b3727691e12ae0da7ce8c785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3984052
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83964}
V8's C++ API does not give a way to tell whether an ArrayBuffer has
been detached from the `v8::ArrayBuffer` class. In fact, as far as can
be told from the C++ API without running JS code, detached
ArrayBuffers behave the same as zero-sized ArrayBuffers and there is
no way to observe the difference. However, this difference can be
observed in JS because constructing a TypedArray from a detached
ArrayBuffer will throw.
This change adds a `WasDetached` method to the `v8::ArrayBuffer` class
to give embedders access to this information without having to run JS
code.
Bug: v8:13159
Change-Id: I2bb1e380cee1cecd31f6d48ec3d9f28c03a8a673
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3810345
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83963}
During String::MakeThin, Heap::ClearRecordedSlotRange might be
invoked on a string in SHARED_SPACE. This can also happen outside
GCs.
Bug: v8:13267
Change-Id: I10d4d7f0b47589127e4a080ce49d69ca7486fc67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985911
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83962}
Since crrev.com/c/3973310 which renamed the isolate scopes, the unit and
cctests for the object-start bitmap and the conservative stack visitor
have broken.
Bug: v8:13257
Change-Id: If8a498827f2085108cf0740a9c5c994145424fc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980255
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83960}
The memory start and size are reloaded after a call in case the call
grows the memory. We should also reload them when the call throws.
We don't need to reload in the 'delegate' case since this will be
handled by the catch handler that it delegates to.
R=jkummerow@chromium.org
Bug: chromium:1377816
Change-Id: Ied1cdb6ed83c1de6a5992df21d776aca9ccf02e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3982115
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83959}
This reverts commit 57db447bf2.
This reland adds handling for Oddballs in Int64Add and Int64Sub in the
SLVerifier and updates the Verifier to check that Int32Constant and
Int64Constant are correctly typed with Type::Machine().
Original change's description:
> [turbofan] Optimize rab/gsab-backed TypedArrays and DataViews
>
> This CL adds TurboFan optimizations for length and element access
> of TypedArrays and DataViews that are rab/gsab-backed.
>
> To enable this optimization, this CL builds the necessary machinery
> required to allow machine operators at the front of the pipeline
> (before simplified lowering). Some key changes to allow this are:
> - Introduce Type::Machine() to allow the typer and the verifier to
> provide a type to those machine operators in parts of the pipeline
> that require nodes to be typed.
> - Add EnterMachineGraph and ExitMachineGraph operators that define
> the boundary between early machine graphs and the normal graph with
> JS semantics.
> - Give Branch operators a BranchSemantics parameter to distinguish
> between machine branches (condition is a machine level value) and
> JS branches (condition is a JS boolean value) and have phases that
> handle branches decide on the branch's semantics based on this
> parameter instead of the position in the pipeline.
> - Extend SimplifiedLowering and SimplifiedLoweringVerifier to handle
> machine graphs. In particular, constants required special handling,
> because they are cached in the graph but they may have uses in both
> a machine and the JS graph, which prevents consistent typing of
> them.
> - Moved lots of logic from JSCallReducerAssembler into
> [JS]GraphAssembler such that functionality can be shared between
> different phases (e.g. JSNativeContextSpecialization and
> JSCallReducer need to generate logic to compute a TypedArray's
> byte length). Extended assembler interface in general with
> additional TNode<> overloads.
>
>
> Bug: v8:11111, chromium:1358505
> Change-Id: Ife006b8c38a83045cd3b8558acbfdcb66408891f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898690
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83881}
Bug: v8:11111, chromium:1358505, v8:13412, chromium:1378439, chromium:1378162
Change-Id: I89702c4be05e0e71cd6836dc50d2e26736a55429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980759
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83956}
We would previously try to preserve field constness if field assignment
was assigning the same value. It's unexpected that real-life code would
be assigning the same value multiple times to an intentionally constant
field, so this was additional bookkeeping with unclear value.
Replace this with not doing it, and considering any write to a constant
field to convert it to mutable. In particular, this means that stores to
existing constant fields in TurboFan become unconditional deopts, rather
than emitting additional code to check whether the value is the same.
Locally, this deopt doesn't fire on our peak-performance benchmarks.
Bug: v8:5495
Change-Id: I12216c5f10a00f42be32c64ca3afe7cf59b4e7f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976516
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83955}
... so that we can add logic to them later for builtin continuation
deopts.
Bug: v8:7700
Change-Id: I03a616243efecb5d637d6ab7d078392a0c51abf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985907
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83953}
This is a follow-up to commit d1a11dd15a.
This reverts commit 9182c028c1.
Change-Id: I4555f329314955e6a4a40dd40e22dc12a570c89e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3986086
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83952}
kDontAdaptArgumentsSentinel is now always equal to zero.
Change-Id: I8f0a930b22cdc88279de66324c23800dd3a93bb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985725
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83951}
We can skip explicit null check for casts from any to a non-nullable
type as they have to perform an instance type check afterwards as part
of the cast and trap if they encounter a non-wasm object (null is not
a wasm object).
The same is true for type checks which fail on null.
Bug: v8:7748
Change-Id: I41ec225618a400feec5dab210fbf7c1bc2718c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981859
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83950}
The inlined version of Array.At was only checking the kind of the
maps, rather than the maps themselves. When the feedback was
containing an array map that "supports_fast_array_iteration", then its
kind was added to the list of supported kinds. If this Array.at was
later called with a non-array map with the same kind, then the object
would be wrongly treated as an array.
This is now fixed: inlining Array.at checks the maps directly rather
than only their kinds.
Fixed: chromium:1377775
Change-Id: I6669ffdc04df04a7c9d00d6b9f8bac82dc9cd235
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981554
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83946}
The newly added cast instructions can cast from {any} type, resulting
in the cast instructions with a concrete type having to also check if
an object actually is a wasm object (and not e.g. a JS object) before
loading the WasmTypeInfo from its map.
Bug: v8:7748
Change-Id: Ia9c1d35fb9de016af4984883f1374fd5238ce6ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981858
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83945}
After concurrent OSR was enabled, JS execution may stop not at OSR entry
when concurrent OSR compilation finish. If no more feedback change,
without reset profiler ticks, OSR urgency is increased from 0 by 1 per
profiler tick after concurrent OSR compilation finish, it makes new
OSR compilation can be quickly triggered, reset profiler ticks after OSR
compilation for triggering the later OSR compilation under the same
condition with the first OSR compilation. For example:
for (;;) {
for (;;) {
} // OSR entry
for (;;) {
<- Executing JS code here when the OSR compilation finish
}
}
1. We start executing the nesting loop.
2. We reset profiler ticks once feedback change.
3. If the first inner loop happens to be executing after accumulating
enough no feedback change profiler ticks, we start concurrent OSR whose
entry belongs to the first inner loop.
4. We continue executing the nesting loop, if no new feedback change,
increasing profiler ticks again.
5. Concurrent OSR whose entry belongs to the first inner loop completes.
6. If the second inner loop happens to be executing, without reset
profiler ticks, we immediately start concurrent OSR whose entry belongs
to the second inner loop.
The second OSR code is almost same quality with the first OSR code.
This CL can reduce OSR compilation amount by ~3.9% (2311 -> 2224) when
running JetStream2.1.
Change-Id: I4d64cd8963fd2b99d88a3c218841fe5d7c4dc34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819421
Commit-Queue: Tao Pan <tao.pan@intel.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83944}
This is a reland of commit 31edec6406
Original change's description:
> [heap] Update young nodes of traced handles
>
> Fix regressions caused by
> https://crrev.com/c/3966952
>
> Update and clear the list of young nodes which would otherwise be
> repeatedly processed during Scavenge and full GCs.
>
> Bug: v8:13372, chromium:1378097
> Change-Id: I1b302f75f970385e9e0259fa4b1719d9262c1f2a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981273
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83922}
Bug: v8:13372, chromium:1378097
Change-Id: I254e1c5c40b5c1cfa06ddd435d5a6610d84e36bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3984605
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83943}
Rolling v8/build: adcb306..4e03165
Rolling v8/buildtools: 4c4e17b..ddc9513
Rolling v8/buildtools/linux64: git_revision:7a6231e3e43845d9aa298bb040f11dd1953e966f..git_revision:3e98c606ed0dff59fa461fbba4892c0b6de1966e
Rolling v8/buildtools/third_party/libc++/trunk: 0487904..baa43f8
Rolling v8/third_party/depot_tools: 1f51102..6f2321d
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221025.2.1..version:10.20221026.0.1
Rolling v8/tools/clang: 863e4bb..87d0b8c
Change-Id: Ieeb9465bd17974caba7cd8f6d1448b5bd7f2b402
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3982514
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@{#83940}
In order to be able to iterate all objects in the heap (including
SHARED_SPACE), all LABs in the shared space need to be iterable. For this reason the HeapObjectIterator needs to perform a global safepoint for the shared heap isolate.
Bug: v8:13267
Change-Id: I2b7583fac0564f8b98b74607404be851fde1281f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3978091
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83939}
It is important that the Context's microtask queue matches what the
embedder thinks it is. Android WebView has some interop functionality
where the Agent changes but the context must not be cleared. Ensuring the microtask queue for the context matches the Agent by adding a
setter that the embedder can call.
BUG=chromium:961186
Change-Id: Id99644fbfc84b8a1676162261444c02d07b238a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976350
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83937}
This extends crrev.com/c/3948663 (ref.cast) by adding the new
"ref.cast null" which only behaves different for null for which
it doesn't trap but instead casts the null value to the target
(null)type.
Bug: v8:7748
Change-Id: I3ac85d83cc06c95af8830c1c60ae2f28414e2570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3960329
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83934}
It looks like a map can become a migration target between
graph building and codegen.
Bug: v8:7700
Change-Id: I88562d69ae62ce5e6c168c73d8ad5eb19099c03b
Fixes: v8:13419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3982113
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: 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@{#83933}
The DCHECK is not correct: if we're marking a not-fully-initialized
object, then the handle can change from its uninitialized value (zero)
to a valid handle prior to this DCHECK, therefore causing it to fail.
This scenario is fine though, since the new entry will already be marked
as alive as it has just been allocated.
To fix that, the DCHECK now allows the two values to mismatch iff the
handle is zero.
Bug: v8:13297
Change-Id: If640d457da1d78a3d1666ffa930c27116a6080c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981553
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83931}
In the constant branch, we need to check if char code is
bigger than zero.
In the generic branch, we do the `andl` before the
comparison.
This also fixes issues with aliasing the code char with
the result register.
Bug: v8:7700
Change-Id: I41a8a22a1acf3feabdee34a61d77c53bcda6892b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981276
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83930}
They do have a meaning as well: there are no unstable maps. When we need
to clear unstable maps (and drop related stable maps), we can avoid
doing this for empty unstable map sets since no unstable maps can have
transitioned to new stable maps.
Bug: v8:7700
Change-Id: Ie74f62b6bff81dff8118a46e22a2ea81550d09c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981278
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83929}
This is a reland of commit 95eece3068
Original change's description:
> [heap] Fix racy OOM in new space concurrent sweeping
>
> Some tests are flakily failing due to a timing issue between new space
> concurrent sweeping and allocations.
> When new spaces and other spaces are also swept, each concurrent thread
> will take one new space page. If a young allocation happens right after
> the atomic pause finished, it's possible that all new space pages are
> held by concurrent threads. The main thread will try to contribute to
> sweeping but get no pages, and fail to allocate.
>
> Fix by restoring the round robin order of sweeping, such that not all
> threads start with new space.
>
> Bug: v8:12612, v8:13413
> Change-Id: I3b448199b4678c339f9e59f7ca31d9e1e0e76011
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976043
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83918}
Bug: v8:12612, v8:13413
Change-Id: Idbd5cbb53c9f43290e02d10d85ee4199ea9a4136
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980756
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83927}
Unstable maps can transition to stable ones after a side effect,
therefore we cannot trust the set of stable maps. The CL nukes
from the set from stable_maps, equivalent of setting it to
the universal set.
Bug: v8:7700
Change-Id: I457f76efd48ec7eec747233ec063ebe265d3085a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3978169
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83923}
Fix regressions caused by
https://crrev.com/c/3966952
Update and clear the list of young nodes which would otherwise be
repeatedly processed during Scavenge and full GCs.
Bug: v8:13372, chromium:1378097
Change-Id: I1b302f75f970385e9e0259fa4b1719d9262c1f2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3981273
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83922}
The deadlock occurs when the Isolate is destroyed before a wasm compile
job is finished causing the `WasmEngine::LogCode` to deadlock itself
when the TaskRunner is already in the terminated state.
Change-Id: I36dc68aecbcb2054d7da61d22defd0eff3130f62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976515
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83921}
