This is a reland of 863bc2b88a
Diff to original:
- Don't eliminate GC observable stores that were temporarily
unobservable during traversal.
- Skip the previously added test for single-generation
- Add new test
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: v8:12200, chromium:1276923, v8:12477
Change-Id: Ied45ee28ac12b370f7b232d2d338f93e10fea6b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320460
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78349}
This is a reland of 2418d22a37
Reland fixes:
* Rebase this 2+ year old change 😱
* Unpoison the kept segment before zapping it to make ASAN happy.
* Carefully adjust allocation size tracking fields to compensate for
kept segment.
Original change's description:
> [zone] Keep one page when we Zone::Reset for reuse
>
> Change-Id: I50c6124d3da5b35d4156c066f38d10d2dc966567
> Reviewed-on: https://chromium-review.googlesource.com/c/1349246
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57793}
Change-Id: Iaffde5b38b3d683af081b1878464dd4c66be5af8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322833
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78348}
This CL overrides the Summarize() method on the BuiltinExitFrame,
similar to what is already implemented on UnoptimizedFrame. This
way the stack trace capturing logic can be unified further, and
only needs to distinguish between JavaScript(ish) and WebAssembly
frames now.
Bug: chromium:1258599, chromium:1278650, chromium:1278647
Change-Id: I15f4dd61199ff047930796ce285bd938e8bcd22f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327142
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78347}
With a recent addition to the type reflection proposal, 'anyfunc' gets
renamed to 'funcref'. For backwards compatibility, 'anyfunc' becomes an
alias for 'funcref'. With this CL, the string 'funcref' can be used to
create a funcref table or a funcref global. Additionally, 'funcref' is
returned as the type of imported and exported functions as well as
globals and tables.
R=manoskouk@chromium.org
Change-Id: If3ed4d507de862ebfcabd4eb967bbfaae1c6ccba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300135
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78341}
Fix is applied to some of halfword signed ops.
Change-Id: Idad3cfe9b66d39cb991974c959d447e5c4eccad3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327722
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78340}
Currently atomic ops on TF are using machine native byte order
and cannot be used by Wasm calls.
This Cl adds support for Little Endian enforced Wasm atomic ops
to PPC/AIX by reversing bytes where needed.
Change-Id: I4080f318022eedd2058e51d09595753eab385441
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327721
Reviewed-by: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78339}
This allows us to reuse AstValueFactory's string table across multiple
parsers, while still releasing memory after each individual parse.
This is mild overkill for all the single parses that don't reuse
AstValueFactories, but there at least the AstRawStrings now end up
grouped together in memory, so that might have mild cache benefits.
Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78338}
To make sure that Wasm memories don't exceed JSArrayBuffer size.
This change shouldn't affect real-world modules, because finding
enough contiguous address space to allocate that much memory is
virtually impossible anyway.
Fixed: chromium:1242339
Change-Id: I68873796b9afb798cb1a64e5e1acc495cf509159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328783
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78336}
Some bad rebasing meant that we were still deleting on the main thread.
As an additional simplification, remove the specific deletion queue
mutex, and just use the compiler dispatcher mutex for the deletion queue
-- this avoids risks of deadlock when both are held.
Change-Id: Ifa4ead6ee3fd814d7f013dd14a5617456afc9f7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328785
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78335}
Rather than requiring the user of a LocalIsolate to pass in a
RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the
scope in the LocalIsolate directly and use its RuntimeCallStats in the
LocalIsolate constructor.
We can't do this for the main thread LocalIsolate, since
WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so
there we use the main-thread RuntimeCallStats instead.
This flushes out some issues of background-thread LocalIsolates being
used on the main thread, so fix those too, as well as RCS scopes using
background counters for operations that could happen on the main thread.
Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78334}
Stub calls generated in wasm-compiler were not marked as kNoThrow. This
created an inconsistency where these ostensibly throwing calls did not
get wrapped in exception handlers, which in turn creates problems in
upcoming changes in inlining.
We resolve the inconsistency by marking all such calls as kNoThrow.
Exceptions are the throwing calls Throw and Rethrow, for which we create
exception handlers in WasmGraphBuildingInterface::CheckForException.
Change-Id: I81da1b191332bcd497116e9f82e4de198778086b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322836
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78333}
During a shared GC we need to iterate the twice: for marking and later
when updating pointers after evacuation. This CL introduces a new
remembered set to avoid the second heap iteration, the remembered set
is created when iterating the client heaps for marking. When updating
pointers, the GC only needs to visit slots in the remembered set.
CLIENT_TO_SHARED is only used during GC atm.
Bug: v8:11708
Change-Id: Ie7482babb53b5f6ca2115daafe6f208acae98d6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315443
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78332}
Rolling v8/build: 9cfc745..312246f
Rolling v8/buildtools/third_party/libc++abi/trunk: 89f2e82..d520ea5
Rolling v8/buildtools/third_party/libunwind/trunk: c8c0ec9..d81cd62
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4983973..d16203a
Rolling v8/third_party/depot_tools: 0a233e1..58c7c38
Rolling v8/third_party/googletest/src: 4c5650f..054a986
Rolling v8/tools/clang: 336fcfd..ed8451a
Rolling v8/tools/luci-go: git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f..git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910
Rolling v8/tools/luci-go: git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f..git_revision:e897e118887a2e6c50a82212b660cb2a7c58d910
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: If2bd3d5e3c62c274ab71b01a562370e7a77bf980
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327745
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@{#78330}
This reverts commit 86038ecfdc.
Reason for revert: Caused TSAN failures
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I32ef7139d4392adfadeffeb70c06f3ed18109ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328782
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78328}
Concurrent marking could still push object to the in construction
worklist after it is emptied at the start of the atomic pause.
Bug: v8:12479
Change-Id: I539e5857001c4689867a3de6adb11142f639cb5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327143
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78327}
Changes:
- Refactor all global base and offset computations into a single
function and simplify GlobalGet and GlobalSet.
- Remove unneeded pointer arithmetic in the simd case. This enables the
use of object operators, including LoadImmutableFromObject, which
might enable more loads to be eliminated.
Bug: v8:11510
Change-Id: Ieab45fd9433863780bcfd6d4596786c08e3951a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320457
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78326}
Design doc: bit.ly/36MfD6Y
We introduce simplified operators LoadImmutableFromObject and
InitializeImmutableInObject. These are lowered to Loads and Stores like
LoadFromObject and StoreToObject.
We split CsaLoadElimination::AbstractState in two HalfStates,
which represent the mutable and immutable component of the state.
Immutable operators in the effect chain modify the immutable half-state,
and plain operators modify the mutable half-state. The immutable part is
maintained through write effects and loop headers. Immutable
initializations do not lookup and kill previous overlapping stores,
assuming each offset cannot be initialized more than once.
Bug: v8:11510
Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78325}
This reverts commit 6b1fb003e1.
Reason for revert: breaks gc stress bots - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36626/overview
Original change's description:
> [stack-traces] Don't hold on to code objects from StackFrameInfos.
>
> Previously every `StackFrameInfo` instance would maintain a reference to
> an AbstractCode object, which was used to resolve the `code_offset` on
> that stack frame. However, it turns out that nowadays this is not
> necessary anymore, since all `code_offset`s reported for JavaScript
> frames are already bytecode offsets and thus can be resolved by just
> looking at the functions' bytecode.
>
> For WebAssembly frames we will also eagerly resolve the `code_offset`
> (which is different depending on whether we're looking at Liftoff or
> TurboFan code) to the byte offset (relative to the function start) and
> stash that away in the `StackFrameInfo`.
>
> For builtin exit frames, the `abstract_code` on the function always
> refers to the builtin code object and thus, there's no point in keeping
> an extra pointer to it around on the `StackFrameInfo`.
>
> This way the `StackFrameInfo` representation is somewhat uniform, and
> more importantly, the `StackFrameInfo` instances will no longer need to
> hold to concrete code objects.
>
> Drive-by-fix: Use `FixedArray::SetAndGrow()` when adding to the elements
> in the `StackTraceBuilder`.
>
> Also-By: szuend@chromium.org, jarin@chromium.org
> Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
> Change-Id: I650e400e0e1acd920281669bdc7b5e1199683ae8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3323073
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78320}
Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
Change-Id: I20643ad8f0c383b754841fc52f9b3447b004c9d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3327141
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@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@{#78323}
Previously every `StackFrameInfo` instance would maintain a reference to
an AbstractCode object, which was used to resolve the `code_offset` on
that stack frame. However, it turns out that nowadays this is not
necessary anymore, since all `code_offset`s reported for JavaScript
frames are already bytecode offsets and thus can be resolved by just
looking at the functions' bytecode.
For WebAssembly frames we will also eagerly resolve the `code_offset`
(which is different depending on whether we're looking at Liftoff or
TurboFan code) to the byte offset (relative to the function start) and
stash that away in the `StackFrameInfo`.
For builtin exit frames, the `abstract_code` on the function always
refers to the builtin code object and thus, there's no point in keeping
an extra pointer to it around on the `StackFrameInfo`.
This way the `StackFrameInfo` representation is somewhat uniform, and
more importantly, the `StackFrameInfo` instances will no longer need to
hold to concrete code objects.
Drive-by-fix: Use `FixedArray::SetAndGrow()` when adding to the elements
in the `StackTraceBuilder`.
Also-By: szuend@chromium.org, jarin@chromium.org
Bug: chromium:1258599, chromium:1077657, v8:8742, chromium:1069425
Change-Id: I650e400e0e1acd920281669bdc7b5e1199683ae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3323073
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78320}
Only initialize the superclass fields initially. The constructor was
using an overload of the same class's constructor instead. In most cases
this still behaved as expected because the {frame_} field would be
overwritten with the right value inside the constructor. But when the
stack segment is empty we would keep the wrong value from the
ThreadLocalTop info instead of {nullptr}.
R=jkummerow@chromium.org
Bug: v8:12191, v8:12485
Change-Id: Iff6a7ea7c8501deaee9ac9f95cd066d965ddbe09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3326241
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78319}
The execute_us is now tied to the --slow-histograms flag.
This currently enabled on a small population as a persistent finch study
which should give us enough coverage for now.
Drive-by-fixes:
- Rename counter: execute_precise() to execute()
- Avoid Leave/Enter overhead in NestedTimedHistogramScope if the
histogram is not enabled
- Only stop timers in debug mode for NestedTimedHistogramScope
Bug: chromium:1275056
Change-Id: Id6a492bdd68edb5194cb191c7083829a9f90283f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320431
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78318}
Parked threads are not allowed to create new handles or access the heap
in any other way. This is a pretty fundamental invariant of our
safepoint mechanism, which doesn't stop parked threads.
Change-Id: I577dbeffbb70e0843644cdc12ffbef022890c364
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3324542
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@{#78316}
This reverts commit 91f08378bc.
Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
This avoids the {StatsCounter::lookup_done_} field by always
initializing the {StatsCounter::ptr_} field in {StatsCounter::GetPtr()}.
This makes the fast path for updating the counter value much simpler and
faster.
R=mlippautz@chromium.org
Bug: v8:12482
Change-Id: I89d094b15e0417bbfb302006de8eede0c200202d
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322768
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78314}
This method has no users in this CL and is a pre-requisite for shared
strings.
Bug: v8:12007
Change-Id: Id8eaf58aa8bb3092c710279c0c9ae0eda5581284
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3321564
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78312}
Initial support for global safepoints kept it simple by entering a
safepoint for each of them one after another. This means
time-to-global-safepoint is the sum of all time-to-safepoint operations.
We can improve this slightly by splitting up the safepoint iteration
into two operations:
1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
and sets SafepointRequested flag for all client threads)
2) Block until all runnning client threads reach a safepoint
We now perform operation 1) for all clients first and only then start
with operation 2).
Bug: v8:11708
Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78308}
Deleting / deallocating Jobs, along with everything they own (e.g.
PersistentHandles), can take a long time, especially if the allocator
isn't too friendly to deallocating on a different thread than where the
allocation happened.
Instead, enqueue Jobs for deletion as part of background processing,
with the hope that they end up being deallocated on the same thread as
they were allocated, and at the very least taking the deallocation time
off the main thread. The deletion queue is processed after the pending
background jobs are all processed, and counts as a single "background
job" as far as parallelism is concerned.
Bug: chromium:1275157
Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78307}
Change the off-thread parse to fill a SmallVector<UseCounterFeature, 8>
on the BG compile task, rather than an int[kUseCounterFeatureCount]
array. This allows us to keep the loop over use counts in the compile
task finalization short by avoiding looping over unused counters.
The value 8 was chosen as a "reasonable small number"; experimenting on
our benchmarks shows a max of 3 use counts collected per compile (and
at a vanishingly low percentage of all compiles).
Passing around an explicit SmallVector<UseCounterFeature, 8> pointer,
complete with size, is a bit ugly, but since it's used only in this one
place (Parser -> BackgroundCompileTask) I can live with it to avoid
further indirections. Typedeffing it is possible, but it's not clear
where, since it's needed in both src/codegen/compiler.h and
src/parsing/parser.h, and neither includes the other.
Change-Id: Idb73e2f56fa9e8911ea29fb810d7562246f19d46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318662
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78305}
With the existing code, V8's --wasm-dynamic-tiering flag gets ignored
in Chrome, because a Chrome flag would override it. With this CL,
the flag --wasm-dynamic-tiering can be used to enable dynamic tiering
explicitly.
R=jkummerow@chromium.org
Bug: v8:12281
Change-Id: I83b8417527872a1a920fcb543932915caf1ed754
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322766
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78304}
scratch is already being initialized to avoid
overwriting offset_reg. We will need to use it instead of ip.
Change-Id: I4ffb93341f64dd8520e2409d6a28783738627ca2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322977
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78303}
Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
the sets and hashmaps, and instead:
1. Turning the pending job set into a queue, and
2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
the LazyCompilerDispatcher::Job, instead of maintaining an
IdentityMap from one to the other.
To avoid bloating all UncompiledData, this adds two new UncompiledData
subclasses, making it four subclasses total, for with/without Preparse
data and with/without a Job pointer. "should_parallel_compile"
FunctionLiterals get allocated an UncompiledData with a job pointer by
default, otherwise enqueueing a SFI without a job pointer triggers a
reallocation of the UncompiledData to add a job pointer.
Since there is no longer a set of all Jobs (aside from one for
debug-only), we need to be careful to manually clear the Job pointer
from the UncompiledData whenever we finish a Job (whether successfully
or by aborting) and we have to make sure that we implicitly can reach
all Jobs via the pending/finalizable lists, or the set of currently
running jobs.
Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78302}
