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}
This reverts commit 5853165291.
Reason for revert: Breaks on gc stress variant - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36600/blamelist
Original change's description:
> [wasm-gc] Allocate supertype arrays in old space
>
> We fix an inconsistency where supertype arrays for wasm-gc object maps
> were not always allocated in old space. To do so we add an
> AllocationType argument to a couple of factory helpers.
>
> Bug: v8:7748
> Change-Id: I8b16032b8504c17e0f730cfc86e30b172645b67b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320455
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78285}
Bug: v8:7748
Change-Id: I74cf52c4f4da8948134f00bcf5415e9c65e509eb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322752
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@{#78286}
We fix an inconsistency where supertype arrays for wasm-gc object maps
were not always allocated in old space. To do so we add an
AllocationType argument to a couple of factory helpers.
Bug: v8:7748
Change-Id: I8b16032b8504c17e0f730cfc86e30b172645b67b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320455
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78285}
On the way to a cheaper and more scalable stack frame representation
for the inspector (crbug/1258599), this removes the need to expose
both what was called "function name" and what was called "function
debug name" on a v8::StackFrame instance.
The reason to having a distinction between that the V8 API exposes
and what the inspector exposes as frame function name is that after
the initial refactoring around v8::internal::StackFrameInfo, some
wasm cctests would still dig into the implementation details and
insist on seeing the "function name" rather than the "function
debug name". This CL now addresses that detail in the wasm cctests
and going forward unifies the function names used by the inspector
and the V8 API (which is not only needed for internal consistency
and reduced storage requirements in the future, but also because
Blink for example uses v8 API and v8_inspector API interchangeably
and assumes that they agree, even though at this point Blink
luckily wasn't paying attention to the function name):
- The so-called "detailed stack trace", which is produced for the
inspector and exposed by the v8 API, always yields the "function
debug name" (which for example in case of wasm will be a WAT
compatible name),
- while the so-called "simple stack trace", which is what is used
to implement the CallSite API and underlies Error.stack continues
to stick to the "function name" which in case of wasm is not
WAT compatible).
Bug: chromium:1258599
Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78283}
With the TLA flag removed, EvaluateMaybeAsync is a misleading name. This
CL renamed EvaluateMaybeAsync to Evaluate and consolidate it with the
sync Evaluate method.
Bug: v8:9344
Change-Id: I376ba9b9af0ac9e40a226cc8454f042ab7d9fb50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3309233
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78282}
This is a reland of 2d087f237e
The changes are :
* Fix redundant reinterpret_cast in test file for MSVC failure
https://crbug.com/v8/12476
* Fix flaky test
https://crbug.com/v8/12475
If a sample is captured during a GC, no embedder context is obtained
defaulting to EMPTY. This is the expected behavior, made it in clear
in implementation and in test.
* Synchronized the embedder context filter behavior with existing
native context filter.
Original change's description:
> Add APIs to surface VMState and new EmbedderState to CpuProfile samples.
>
> EmbedderState:
> * An EmbedderState is defined as a value uint8_t and a v8::context used
> for filtering.
> * EmbedderStates are stack allocated by the embedder, construction and
> destruction set/unset the state to the isolate thread local top.
> * A v8::context is used to filter states that are added to a CpuProfile,
> if the CpuProfile do not have a ContextFilter set or if contexts do not
> match, state defaults to Empty.
>
> * v8:StateTag is already propagated all the way to a Sample, simply add
> an API to surface it.
>
> VMState:
> Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e
> Bug: chromium:1263871
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072
> Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78250}
Bug: chromium:1263871
Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037
Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78281}
We introduce a minimum length for the supertype array of gc maps. When
the depth of the rtt is known to be smaller than that length, we can
type check without bounds checking the supertype array of the object
map.
Bug: v8:7748, v8:11510
Change-Id: I88e67871040a8c4dd219e48a84527f7f3f3d0a96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312487
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78280}
Counter updates were already atomic, but reading the counter values was
not. This lead to data races if one isolate called `quit` while other
isolates were still running.
This makes counters fully atomic, and reflects that by making the fields
{std::atomic<int>}.
R=mlippautz@chromium.org
Bug: v8:12481, v8:12482
Change-Id: I6fc78ad6461b93c4b3e87bec052b0a67694539e3
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/+/3320428
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78279}
D8 shares counters across isolates, so even if they are only updated
from the main thread, they need to be thread-safe.
This CL removes the distinction between {StatsCounter} and
{StatsCounterThreadSafe}, and just makes all {StatsCounter} use (cheap)
atomic operations for counter updates. This will make previously
thread-safe counters cheaper, because no Mutex is involved. It might
make previously not-thread-safe counters slightly more expensive, but
it's not expected to be a significant regression.
R=mlippautz@chromium.org
Bug: v8:12481, v8:12482
Change-Id: I47b8681c1cf26d142e1ccfafa0c192e3fdcb7d2a
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/+/3320427
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78278}
This reverts commit 863bc2b88a.
Reason for revert: https://crbug.com/1276923
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: chromium:1276923
Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78277}
Checks whether a Persistent is used from the creation thread on slow
path allocations. In practice, these currently happen every 256
Persistent allocations. This is a best effort check that may help to
flush out issues that are missed with DCHECK builds.
Bug: chromium:1276570
Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78276}
Allocating a temp register in a conditional branch confuses
the LiftoffAssembler's state tracking, so this patch moves
allocation of the register into the unconditional part of the
control flow.
Fixed: chromium:1275711
Change-Id: Ic83ba8c098c5edb33d035c1a93931d54cc1f1caa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320423
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78275}
This CL adds the following specific cases, to make sure they are
correctly handled by the slow path:
- the backing store of a TypedArray gets detached after optimisation
- passing null instead of a TA doesn't lead to a deopt
Bug: v8:11739, chromium:1052746
Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78274}
Field used to be atomic for AssertActive() but now that this method
uses another approach, we can make that field non-atomic again.
Bug: v8:11708
Change-Id: I5254aa5e655844739082144fc75ba9f0c13d1ba0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3317424
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78273}
