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}
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}
Rolling v8/build: 0d9559b..9cfc745
Rolling v8/buildtools/linux64: git_revision:e0afadf7a743d5b14737bd454df45d5f1caf0d23..git_revision:fc295f3ac7ca4fe7acc6cb5fb052d22909ef3a8f
Rolling v8/buildtools/third_party/libunwind/trunk: 74c6eec..c8c0ec9
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/02439f6..4983973
Rolling v8/third_party/depot_tools: 82f3512..0a233e1
Rolling v8/third_party/googletest/src: d61d4d8..4c5650f
Rolling v8/tools/clang: fb06cff..336fcfd
Rolling v8/tools/luci-go: git_revision:81212ba3aa0a1a724465bded12d12c16ed46da3a..git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f
Rolling v8/tools/luci-go: git_revision:81212ba3aa0a1a724465bded12d12c16ed46da3a..git_revision:31175eb1a2712bb75d06a9bad5d4dd3f2a09cd1f
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ife5892b51ffbc008a2f15bee4df6ebec29124b59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322892
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@{#78298}
Normal Wasm load/stores currently go through a byte
reversing pipeline. Atomic load/stores however do not go
through it and as a result do not produce the correct result on
Big Endian platforms.
This CL is adding this functionality to wasm-compiler by
introducing a new macro `CASE_LOAD_STORE` which takes in an
additional input `wasm::ValueType` needed by
BuildChangeEndiannessLoad and Store.
Change-Id: I138c6ea8baa07222cd86a791d70cb586e5594e97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3316032
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78297}
All uses of the build flag will be removed in a follow-up CL.
Bug: v8:11112
Change-Id: Ifc3d9ed5d642646edeba51aa6d60924796d0f788
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322769
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78294}
Ensure the bytecode array is available, before we put it to the
PendingOptimizationTable.
Bug: v8:12416
Change-Id: Ie4eb1a8a2ebdcdc0cfbfd7884eb081e156635a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313108
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78293}
Make the block defining the counter names more organized, and mostly
clang-formatted.
This slightly changes the name of the CODE_TYPE and FIXED_ARRAY
counters ('-' -> '_'), but none of them are used in chrome or in
benchmarks, so this should be fine.
R=mlippautz@chromium.org
Bug: v8:12482
Change-Id: I4aa7d4e11a4f498f9adb092e3b98e1edf68401dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320454
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78292}
Treat all stack pointers as roots:
- Maintain a global linked-list of StackMemories
- Update StackFrameIterator to process inactive stacks
- Visit roots in all inactive stacks (including root marking and root
pointer updating).
Drive-by:
- Fix some issues uncovered by the test
- Refactor the builtin constants
R=mlippautz@chromium.org,ahaas@chromium.org
Bug: v8:12191
Change-Id: I5b6381f9818166e2eabf80dd59135673dddb2afc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310932
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@{#78291}
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
which stores a couple of pointers and most importantly the Zone and
AstValueFactory of the parse. This allows the Zone and AstValueFactory
to be reused across multiple parses, rather than re-initialising
per-Parse.
With this, we can amend the LazyCompileDispatcher to initialise one
LocalIsolate, Zone and AstValueFactory per background thread loop,
rather than one per compile task, which allows us to reduce per-task
costs and re-use the AstValueFactory's string table and previous String
internalizations.
Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78289}
