Normally, taking a heap snapshot in the near heap limit would
result in a full GC, then the overhead of the promotions would
cause another invocation of the heap limit callback and it can
raise the limit in the second call to avoid an OOM, so we test
that the callback can indeed raise the limit this way in this
case. When there is only one generation, however, there would
not be the overhead of promotions so the callback may not be
triggered again during the generation of the heap snapshot.
In that case we only need to check that the callback is called
and it can perform GC-triggering operations jsut fine there.
Bug: v8:12815
Change-Id: If244417624b56bc068aed480fb3391d26c19005a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600357
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#80094}
In the simplest way possible.
Bug: v8:7700
Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80089}
This reverts commit 2d394acac4.
Concurrrent marking for v8::TracedReference requires a single bit in
global handles to be written concurrently. While no other bits require
concurrent access, initialization still needs to properly publish the
the bitfield. Publishing generally allows all bits to be read on any
thread which is already used for some.
The CL introduces acq/rel semantics on the actual object pointer for
publishing the state.
Bug: chromium:1315498, v8:12600
Change-Id: Ic50c7c0b647b8b609bcd899f6c9f73bee80303da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596125
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80085}
Fixes the iteration after emitting an unconditional deopt to kill all
Jumps along the way, not just ones preceeding a merge point. This fixes
several issues:
a) That Jump may be to a not yet created merge point, in which case we
were getting a nullptr deref.
b) Not-yet created merge points would not be detected as merge points,
so we'd skip over them and miss killing the control node before
them.
c) We weren't reducing predecessor counts, so even after fixing the
nullptr deref above, merge states created later would have the wrong
predecessor count.
Now, we check bytecode targets (including fallthrough for non-returning
bytecodes) on for every bytecode, and skip over both not-yet created
merges, and loop merges that have no predecessors other than the loop
jump itself.
As part of this, the dead predecessor merging is changed; instead of
setting the predecessor to nullptr, we drop the predecessor count by
one, and trim any Phis' input counts.
Bug: v8:7700
Change-Id: I904c82df7c5dd44d7637e07f6750b35e7e219284
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599470
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80083}
When moving forward and optimizing internals, these APIs cannot be
trusted anymore as their semantics are tangled to the current
implementation.
Bug: v8:12819
Change-Id: I0e3370724307a420ee42fed8070b55542be9400d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599475
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80082}
Adds LogFunctionCompilation as a static member of Compiler.
Calls the log function after installing the code on the main thread.
Bug: v8:12054, v8:12818
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Change-Id: I664b2c890292a207720efe311b7c55757c7c6470
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599472
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80080}
Removes V8-internal support for resurrecting finalizers in the garbage
collector.
The APIs have already been removed in http://crrev.com/c/3596174
Bug: v8:12672
Change-Id: Ia507e74659b61a2c8c08281d7f395aee51e3fe17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3584115
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80078}
Add a --maglev-inlining flag, and add some half-baked support for
inlining functions when there is call feedback.
When the flag is enabled and there is call feedback, we create a nested
MaglevGraphBuilder for the current graph, and pause building the graph
of the outer function. We manually set up its prologue to set up its
frame with the arguments pass into the call, build the body with the
nested graph builder. This inner builder knows that it is building an
inlined function, and all Return bytecodes will instead emit a Jump to a
single merge block at the end of the function, where execution of the
outer function can resume.
These inner function basic blocks are wired into the outer graph with
new JumpToInline and JumpFromInline control nodes. The idea is that
subsequent passes will know what the inline function is, and will use
these to manage the function stack (particularly for codegen and
especially deopts).
Bug: v8:7700
Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80077}
"Iterate" takes an iterable and a function of TNode<Object>, and
implements the iterator protocol to iterate the iterable, applying the
function to each element.
It handles exceptions thrown during iteration and closes the iterator as
appropriate -- the hope is that if the body of the iteration has no
exception-throwing nodes, TurboFan can dead-code eliminate this close.
In the future, we may want to add an array fast-path to this method;
centralising the implementation means that this fast-path will then be
used by all callers of Iterate.
Change-Id: I9fe2f862b78619fe21ea7cb6469ed7ba93f14a30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581770
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80075}
When an object changes layout, OLD_TO_SHARED slots need to be
invalidated for it as well.
Bug: v8:11708
Change-Id: I28ea181012955fddef986e8f8806a7477307df28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596175
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80071}
Removes support for specifying weak handles with finalizers that allow
for object resurrection.
This CL removes the public facing APIs. Internal support will be
removed in a follow up.
Bug: v8:12672
Change-Id: Ia6ea269093aaa128caadb7508aca2e5a1254923c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596174
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80070}
As ecma262 normative change https://github.com/tc39/ecma262/pull/2683,
exception thrown on PromiseResolve the broken promises need to be caught
and use it to reject the promise returned by
`AsyncGenerator.prototype.return`.
AsyncGeneratorReturn didn't handle the exception thrown by Await. This
CL add an exception handler around it and pass through the caught
exception to the returned promise and resume the generator by
AsyncGeneratorAwaitResume if the generator is not closed, otherwise
reject the promise by AsyncGeneratorReject and drain the queue.
Bug: v8:12770
Change-Id: Ic3cac4ce36a6d8ecfeb5d7d762a37a2e0524831c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581158
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80066}
Besides, enable float support on simulator.
Port commit 098f31f495
Port commit a6da816119
As defined in
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention
Loongarch calling convention uses GP to pass floating-point
arguments when no FP is available.
Bug: v8:12614, chromium:1052746
Change-Id: I33d4115674604604b2b7e9178a306efb6000222b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3448195
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yu Liu <liuyu@loongson.cn>
Auto-Submit: Yu Liu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#80062}
- Use explicit options when running gmcole.py from run-gcmole.py
- Use gcmole.py-relative paths to find the default V8 root dir for
maximum convenience when running locally
Change-Id: Iba0da90b99b0321129f1c4099f437c76dabb1186
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3582386
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80058}
We do change CWD in the script which breaks relative input paths
to d8 and .js files for instance.
Drive-by-fix:
- Show clear warning if `perf record` failed
Change-Id: Ib900ca6b53307e13be459beba1e96ddfc8ee9b79
No-try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593784
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80057}
The register allocator might be able to choose between a floating
or general registers.
Bug: v8:7700
Change-Id: Ib74b8c6cd5db12ae34b7f08cd2aeb21ffd3bac33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596121
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80054}
This adds the OSR state to the FV, where the state consists of the
osr_urgency (same semantics as previously on the BytecodeArray) and a
maybe_has_optimized_osr_code bit (set if any optimized OSR Turbofan code
exists for this function).
The two are packed into one field for efficient OSR checks in generated
code (to be implemented in the followup CL).
Bug: v8:12161
Change-Id: Id4edb8f5db0bf02e0d04b87aeec8d8c53e213503
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596120
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80053}
MaglevCompilationInfo stores the overall compilation information (zone,
graph, labeller, etc.), while MaglevCompilationUnit stores per-function
information (function, bytecode analysis, register count, etc.).
Without inlining, these are 1:1 and we've been pretty sloppy in deciding
which to pass around. Once we implement inlining though, we want to be
careful to pass MaglevCompilationInfo where we're processing the whole
graph, and MaglevCompilationUnit where we're processing something
function-specific.
This does the pre-work of cleaning this up in preparation for inlining.
Bug: v8:7700
Change-Id: Ic50fdd97e56f6c963ab490bd419eb65fe0873688
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596162
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80051}
Reason for reland: Fixed Fuchsia build.
Original change's description:
> [builtins] Remap builtins on Linux
>
> This is a CL similar to
> https://chromium-review.googlesource.com/c/v8/v8/+/3553006, but on Linux
> rather than macOS. The goal is to allow builtins to use short builtin
> calls without paying a memory cost, by remapping rather than copying
> them.
>
> However, while macOS has a system call making this easier, on Linux we
> don't have one on most kernels. There is the recently-introduced
> mremap(MREMAP_DONTUNMMAP), which is available in 5.7, but only works on
> anonymous mappings until 5.13, which is too recent for most Android
> devices.
>
> Instead, we open() the file containing the builtins, and mmap() it at
> the desired location.
>
> Change-Id: I4524f349948b8f48c4536cf392a1cd179662a6cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570426
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80022}
Change-Id: I0cc8cf510bd2cb8621130bea8406d79aa209948c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596164
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80049}
.. which points back at the corresponding feedback vector slot for each
JumpLoop bytecode.
Bug: v8:12161
Change-Id: I95f4d013544a69e088314655af7eb1dc504a8657
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596166
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80048}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds a new optional flag `canBeRestarted` to every call frame
in Debugger.paused events. As the name suggests, the flag indicates
whether we can restart a particular frame through Debugger.restartFrame
once implemented.
We are not able to safely restart all frames:
* We don't support WASM frames
* We don't support frames where resumable functions (async fns,
generators) and embedder C++ frames are between the top-most
frame and the to-be-restarted frame.
Note that from a CDP perspective the flag doesn't actually guarantee
a successful restart. CDP clients can issue
CDP commands between the Debugger.paused event and before a user
decides to restart a frame, which can potentially mess
with the stack.
The `canBeRestarted` flag tests are folded into the
Debugger.restartFrame tests. As the feature is not yet fully
implemented we short-circuit most of the tests for now and only
run them up until the first Debugger.restartFrame call fails
(except "fails-for-resumables.js").
This means the tests exercise the `canBeRestarted` flag, but not
the restarting functionality itself.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I01ab46dc3557ab8383960969fbe03e00604cc5e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596160
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80046}
These will soon be used to store cached OSR code.
Bug: v8:12161
Change-Id: I49b6f1cd648e1fd033ac09b2e590bc185f5461e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596165
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80045}
