FLAG_wasm_dynamic_tiering is still off by default. When enabled,
it now uses the technique previously behind --new-wasm-dynamic-tiering.
Bug: v8:12281
Change-Id: I365c2c066e62418cd6abc7830f95d1fe0f950e33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275570
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77883}
The entered contexts stack must be in sync with the flags stack.
Bug: chromium:1269225
Change-Id: Ibb522286b47866d5f13aaec1a0a02914c13a5545
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3279680
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77882}
When incrementally marking a non-shared heap, shared values should not
be marked. Similarly, non-shared values should not be marked when
incrementally marking a shared heap.
Bug: v8:11708
Change-Id: Iecd799e7e3060e5fb3897b8be0c4e8158d9ff57f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3278673
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77881}
Under certain conditions GC could flush bytecode array from
SharedFunctionInfos. This CL ensures that the bytecode array is always
available for reconstructing source positions.
Bug: chromium:1265570
Change-Id: I2ce7eb04201f69121687ab0aaa2af42adb2caae0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275569
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77877}
Switching stack affects all instances, therefore make the active
continuation a root object instead of an instance field.
Bug: v8:12191
Change-Id: Ia521bf4e7c3cbca035f916e47804c2f75bbd8f18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268296
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77876}
This shadows ATOM used in js-regxp.
Making this an enum class requires changing a lot of different places.
Atom is an Intel brand name, so INTEL_ATOM kinda make sense.
Bug: v8:12244,v8:12245
Change-Id: I80be342488328cde5aaca36f900375d2fb381253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3276926
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77875}
UnprotectAndRegisterMemoryChunk should only be called if we have
CodePageCollectionMemoryModificationScope or
CodeSpaceMemoryModificationScope open.
This also fixes cctests that create code objects without a
code modification scope.
Bug: v8:12054
Change-Id: Id931f1f8120050b2bb76ef3d5701b9a32e52ff37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277882
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77873}
Unify parse post-processing between main-thread and background-thread
parsing, now that we have LocalIsolate and can Internalize on background
threads.
As part of this, simplify the LocalIsolate parking pattern to explicitly
park during ParseOnBackground, rather than being implicitly parked when
ParseOnBackground is called. This reduces the amound of scoping needed
in the BackgroundCompileTask::Run method.
Change-Id: Ifdb128b763129bda78bd1bae89dac1c62f872350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277876
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77872}
When closing a concurrent allocator, for instance when closing a
LocalHeap, we need to make the LAB of the code space iterable.
We add then a CodePageMemoryModificationScope to allow
code space modification.
Bug: v8:12054
Change-Id: I438d7c1a50694930b7558dec2dd552bec22b7552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277887
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77871}
Speculative fix for a data race involving memory measurement. For memory
measurement we use JSGlobalObject::native_context_unchecked in
NativeContextInferrer::InferForJSObject when trying to infer the
NativeContext for a JS object from a concurrent marking thread. This
load can race e.g. with the context deserializer running on the main
thread. Fix this race by making the load relaxed atomic.
Bug: chromium:1269681
Change-Id: Id04a92572d7d722594b2f8465e579b7231e54e29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277885
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77870}
Due to streaming, the SFI enqueueing can happen concurrently with with
main-thread finalising, so we need to add locks around accesses to the
SFI->Job map.
Bug: v8:12370
Change-Id: I60281a954ef10f7fcde559b9529077a6b9a82c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277874
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77869}
The DCHECK ensures that a page that is going to be destroyed is not
anymore part of the vector of pages of a space. This DCHECK runs while
a potential concurrent sweeper task may add a page for a live object
to the vector, resulting in a broken iteration. Use the pages lock to
fix this.
Bug: chromium:1268969
Change-Id: Ice87026957b3e6b5d36cf28293f7aa6901e96ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277132
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77867}
Rolling v8/build: 2f14357..f38f611
Rolling v8/third_party/aemu-linux-x64: j1lOwTKOsgGUj2jDFDa6IhTVhwEoPPzmdxFksCvz278C..eWKIKAWWZAJd3aNVfwGevVWupHnf0a31BNfVmvJfkucC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/0dab16a..279fe4e
Rolling v8/third_party/depot_tools: 2df8443..0b187dc
Rolling v8/third_party/googletest/src: 79efd96..9ca071b
Rolling v8/third_party/instrumented_libraries: 286f857..380f371
Rolling v8/tools/luci-go: git_revision:d17c642c8c3c6d9e37bd9c25535c4c5b66b99781..git_revision:bf56a119c5f056a1f7a04c8dbe19cdd86728b540
Rolling v8/tools/luci-go: git_revision:d17c642c8c3c6d9e37bd9c25535c4c5b66b99781..git_revision:bf56a119c5f056a1f7a04c8dbe19cdd86728b540
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: If831f3ede3b0e01ad34b4901448b7482f6c64d33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275842
Reviewed-by: 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@{#77863}
Port 9a900169f8
The second parameter of Int64Mul may be a 64-bit immediate value,
treating it as a 32-bit value will lose the upper 32 bits.
Bug: v8:12373
Change-Id: Ib824db839219307ba390a6dc3c697bedb792046f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275135
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77862}
This fixes a -Wshadow warning for NO_FLAG. The other option is to
make it an enum class, which makes test-conversions.cc a bit verbose.
Bug: v8:12244,v8:12245
Change-Id: I3ea429eb45e31b25d4c6658ceb86c33ba280ae51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3274015
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77860}
My previous change https://crrev.com/c/3160299 introduced a runtime
CHECK that crashes the process if V8 attempts to read a deoptimization
literal which has been cleared. That CHECK is indeed crashing the
process.
It appears that the trouble arises in cases where the deoptimization
data indicates that an object should be materialized as needed. In those
cases, one of the deoptimization literals is the Map to use when
materializing the object. It is possible to reach a part of the code
that requires the materialized object, and therefore the Map, without
there being any other owner of that Map. This is in contrast to most
other deoptimization literals, which are logically equivalent to omitted
values from the stack frame and therefore can't be reached without a
real owner somewhere to keep them alive.
To fix, I propose referring to Maps strongly from the deoptimization
literals. The cases I investigated in v8:4578 didn't involve Maps, so I
believe that the observed memory leaks are still fixed with this change.
Bug: chromium:1268681, chromium:1268683, chromium:1268825, v8:12300
Change-Id: Ifd32a7f9cc29e0384650013ab16e05646bf57895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272880
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77857}
Similar to previous bug v8:11771, this test needs deterministic GC
behavior so it is incompatible with concurrent inlining.
Bug: v8:12374, v8:4578
Change-Id: Ib3667744d1032524a0c2e697a970876dfc1677ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272882
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77851}
The check is a simple shortcut, but this is not safe in multithreading.
In a multi-threaded situation, if a CodePageCol**Scope is open while
a CodeSpaceMem**Scope is already opened, the result is a noop.
If the latter finishes first, then we would decrement a wrong
depth in ~CodePageCollectionMemoryModificationScope.
Bug: v8:12054
Change-Id: I7e1016628ffbd37b343ea130eb8d7d8e60abec98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275562
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77849}
Loop headers in the interpreter would start a new basic block, which
among other things would reset the liveness of that block. This meant
that a loop created after dead code, without a check for whether the
code is currently dead or not, would "resurrect" that block's liveness,
making the inside of the loop live even though the loop itself is
unreachable.
This works fine, since the loop is still unreachable, but can breaks
DCHECKs in bytecode liveness analysis for cases where a register is
supposed to be initialised before the loop, in the dead code, and is
then used inside the loop, in the resurrected code.
Normally this wouldn't be a problem, since blocks are normally killed on
the statement level and we check for deadness during statement
iteration, but `foo() = x` introduces an expression-level block killer
(being re-written to `foo[throw ReferenceError] = x`) and we don't check
for deadness after assignment Lhs preparation.
This does mean that we have to fix the InterpreterJumps test, to not try
to jump into the middle of a loop (since this could revive the loop).
This can only happen when manually creating bytecode, bytecode generated
from JavaScript is always reducible.
Bug: chromium:1230597
Change-Id: I8403ccdeae7e5450adf629026e2ca8a134c81877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275557
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77846}
This reverts commit 90a9d6cb13.
Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.
Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
Changes:
- Enable allocation folding for wasm-gc graphs.
- Improve structure of wasm escape analysis code. Kill dead nodes.
- Revisit object node after eliminating a load or a store to that node.
- Add a couple of tests, rename one test file.
Bug: v8:11510
Change-Id: I8b3c5186cd0a8827744a05eba366ff79bc7bc975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264215
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77840}
... by
1) using platform-specific kMaxPCRelativeCodeRangeInMB constant
instead of fixed 2GB for computing a region around embedded builtins
from which the builtins could be reachable by pc-relative call/jump
instructions,
2) remapping builtins into the code range if the latter happened to be
allocated too far from embedded builtins (so that the pc-relative
calls/jumps can't reach the embedded builtins blob).
Bug: v8:11880
Change-Id: I3c8df6836a8f0156d5360edd9c4ae8c295ec7100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270543
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77837}
