- Avoid redrawing property-link tables if the contents don't change
- Don't update timeline legends if the selection doesn't change
- Use shorter class names for the flamechart for faster parsing
- Round positions in flamechart to avoid long strings that would be
created from raw double positions
- Don't redraw the tooltip if the content is the same
Change-Id: I925f1708400286c7c9f8db62f75c3b5fe8a16b12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3521945
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79540}
This implements the last bits of basic concurrent Maglev compilation.
When jobs have been processed, schedule an interrupt to trigger codegen
and building the Code object on the main thread.
Changed since the initial version:
- Put the include behind V8_ENABLE_MAGLEV.
- Skip 18.js until we have deterministic test helpers for concurrent
tiering.
Bug: v8:7700
Change-Id: Ibc103f097fe00f7df93a33a785939e43901f3734
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536662
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79539}
Avoid instruction selector to emit sign extension instruction after most
`xxx.w` instructions in RV64I and RV64M, because `xxx.w` instructions
will automatically sign-extend the result
Change-Id: Ia4291242dc3e51f49be1e6dda2d5a3365b5e7bfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536845
Reviewed-by: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#79537}
Will re-enable once a few issues have been resolved.
Change-Id: Ieed60efcb6d59cc5ca10931913dd4d9ffea8b9f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3532202
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#79533}
This is a reland of 48b443f692.
While fixing the initial CL, we stumbled upon a few bugs that
we had to fix:
- CommonOperatorReducer and SimplifiedOperatorReducer were applied
before and after SimplifiedLowering, but always assumed that it
was before SimplifiedLowering, and thus had the wrong semantics
for branches in some cases. They now have an added parameter to
know which semantics of branch they should use.
- The lowering of StaticAssert was wrong and could leave kHeapConstant
in the assert (instead of machine Booleans).
Original change's description:
> [compiler] Simplify "==0" branches in MachineOperatorReducer
>
> Bug: v8:12484
> Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Owners-Override: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79379}
Bug: v8:12484
Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79528}
This reverts commit cf25b3bc53.
Reason for revert: https://crbug.com/1307471. TraceTrait must only be used during marking.
Original change's description:
> cppgc: Rework prefinalizers
>
> Move the check for whether an object is live or dead out of the
> prefinalizer trampoline. Moving it into the backend allows for
> inlining the check which avoids a call to the trampoline for live
> objects.
>
> On catapult benchmarks (e.g. cnn:2021, nytimes:2020), there's often
> ~2k finalizers registered. In order to avoid memory overhead in the
> range of a few KB, we store the fact whether the object points to the
> base object payload in the LSB of the pointer. For caged builds this
> is replaced with just storing the index into the cage for both object
> and base object payload.
>
> Locally saves around ~10% of atomic sweeping processing time which is
> in the order of .05ms.
>
> Bug: v8:12698
> Change-Id: I198205a6b1d57fc2df821ee4e73e53dc6f825ff5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497764
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79442}
Bug: v8:12698, chromium:1307471
Change-Id: I5c4e70d46cb99af66c77f0c013625b6af6c6eb8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535781
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79527}
There are problems calling WaitForRunningWorkers when we
call quit().
First, suppose the main thread first calls quit(),
and the worker thread calls quit() after the main
thread calls quit(), then sched_yield to wait for
quit_once_ updated to ONCE_STATE_DONE. However
the main thread is WaitForRunningWorkers to wait
for the worker thread to join, thus causing deadlock.
Second, suppose the worker thread calls quit() and empty
the running_workers_ by WaitForRunningWorkers, then
the main thread calls `onExit(isolate, true)` to dispose
the platform and other global data, which will crash other
running workers.
Bug: v8:12219
Change-Id: I333e5aad431daefb1c163f69e66d8e9d5e9bf754
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518908
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79525}
This implements the last bits of basic concurrent Maglev compilation.
When jobs have been processed, schedule an interrupt to trigger codegen
and building the Code object on the main thread.
Bug: v8:7700
Change-Id: I348ade4777ddddf7c3a6b0575d9f51e5fa00c9fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528494
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79516}
.. into new virtual subclass TurbofanCompilationJob. Update all TF code
to derive from this class. Specifically, the OptimizedCompilationInfo is
TF-specific and now lives in TurbofanCompilationJob.
The motivation behind this is that Maglev now also uses this
infrastructure.
Drive-by: Replace CompilationMode with ConcurrencyMode.
Bug: v8:7700
Change-Id: Iae6d1ffd1c810e2e45cad6c9b4e43d4c82ac54a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528493
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79515}
In JSCallReducer::ReduceArrayPrototypeShift, add Unsigned32
TypeGuard for index Node used in fast path, avoid representing
kRepFloat64 (Range(1, inf)) to kRepWord64 when converting
input for kLoadElement.
Bug: v8:12632
Change-Id: I2e4b00840dc5462e4351e13a372c33b6272b9ea1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528373
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79514}
This started out as a minor code move of early-osr logic, but
became a more general refactor of the tiering decisions.
Early-OSR: the intent here is to trigger OSR as soon as possible
when matching OSR'd code is cached. Move this out of ShouldOptimize
(since it has side effects), and into a dedicated function that's
called early in the decision process.
Note that with this change, we no longer trigger normal TF optimization
along with the OSR request - TF tiering heuristics are already complex
enough, let's not add yet another special case right now.
Other refactors:
- Clarify terminology around OSR. None of the functions in TM actually
perform OSR; instead, they only increase the OSR urgency, effectively
increasing the set of loops that will trigger OSR compilation.
- Clarify the control flow through the tiering decisions. Notably,
we only increment OSR urgency when normal tierup has previously been
requested. Also, there is a bytecode size limit involved. These
conditions were previously hidden inside other functions.
Bug: v8:12161
Change-Id: I8f58b4332bd9851c6b299655ce840555fb7efa92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3529448
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79512}
- Restructure the runtime function implementation.
- Rename osr_loop_nesting_level to osr_urgency and add helpers.
The motivation for the latter: I've always struggled with the
`osr_loop_nesting_level` term; it neither matches terminology of
what it's compared against (= the loop depth), nor implies what it's
used for (= osr is triggered when `loop depth < osr nesting level`).
In this CL it's renamed to `osr_urgency` to reflect that as urgency
rises, we consider more and more loops as OSR candidates.
Bug: v8:12161
Change-Id: I194ec5a3f1f02526641af1c7796ee0956b6fd3a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528735
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79509}
CL https://chromium-review.googlesource.com/c/v8/v8/+/3514072 tried to
improve code generation for patterns like "x >> n == k" when n and k
are constant, and to generate instead "x == k << n" (with "k << n"
being computed at compile time).
However, this was also done when "x >> n" was reused later, which
caused "x" to be kept alive longer that it could have, which could
increase register pressure.
This CL thus ensures that this optimization is done only if "x >> n"
has a single use.
Bug: chromium:1305389
Change-Id: I377e120c4825e2a0deb4a5478138da838bcebc77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528987
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79502}
We check if debugger needs to hook into every call when we enqueue
the function to batch and when we compile, but we do not check it
when we install it (that is, set_baseline_code), which is done in
the main thread.
Bug: v8:12713
Change-Id: I81ba221caed1060976e8865174d392a861f2ab24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528988
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79500}
Please revert this CL if it causes any trouble!
Bug: v8:11111
Change-Id: I6061fdc0aed82952f093ede9ecd252be1ac99519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528495
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79499}
In text, we should use the properly capitalized "Wasm" instead of
"WASM". In particular for frame output, other frames typically use
CamelCase (like "JsToWasmFrame", "ExitFrame", "InternalFrame"), so Wasm
should do the same.
The "0xa" comment in some assemblers is also outdated, the current tag
we emit for StackFrame::WASM is 0x8 (0x4 shifted by one).
R=jkummerow@chromium.org
Bug: v8:12425
Change-Id: Ic3e00c401b219c28b5424c82efb0f1a9df51690f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3525195
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79498}
JSObject::InitializeBody now checks whether the instance type of the
object being initialized can have embedder data slots around the
initialization logic for these slots. This fixes a performance
regression on certain benchmarks.
To perform this check efficiently, a new instance type,
JSObjectWithEmbedderSlots, is introduced so that the check becomes a
simple range check.
Bug: chromium:1304139
Change-Id: I00c892bc2276e950b59602257ca1c2435c10e517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3507712
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79497}
This method now handles external pointers in HeapObjects during
serialization by encoding the representation of the external pointer
(sandboxed, raw), the origin (internal, api) and potentially the
external pointer tag. It is currently only used to handle
JSExternalObjects but could, in the future, be extended to handle all
external pointers that need special handling during
serialization/deserialization.
Bug: v8:12700
Change-Id: Ib0747d765ddc632e4ca4ee94521616d0271be0bc
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3521904
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79496}
