Now we compute the max number of outgoing arguments during bytecode compilation, and store this value on the bytecode array. It's reused by sparkplug; and by the optimizing compiler to ensure they can compute the right max unoptimized frame size for stack checks.
Bug: 341216494
Change-Id: I16e2582e397d8c7847a40e58a8a1b45be880333f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5577683
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94196}
This will help us to figure out what .initialize we're calling in
octane/raytrace despite it being megamorphic. It's the first call after constructing the instance, so we'll know the map of the
instance. It doesn't work yet though since the arguments object creation
is currently nuking the map info for the receiver before the actual
.initialize load. We know those allocates can't alias though, so we
shouldn't nuke the info. That's follow-up work.
Bug: v8:7700
Change-Id: I7b4e2f316a449355de1796f5c391c85a429227ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5569671
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94079}
If we already have known node feedback, we can refine recorded feedback.
This allows us to e.g. drop repeated TransitionElementsKind* nodes.
(Small side improvements: turn AddNewNode<CheckHeapObject> into
BuildCheckHeapObject to avoid unnecessary checks.)
Bug: v8:7700
Change-Id: Ie9419ee3d8b646c84a4440d38632ffa9cfd625fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5545560
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94004}
We only need to save/restore pending messages when we're catching and
rethrowning an exception, so push the code to paths that handle
CMD_RETHROW. (We always pass through RETHROW if we caught since we might
rethrow. This could be overwritten later of course, in which case we
won't restore.)
Change-Id: Iab00a2b2e141ffda978324e08c85ee05c2cd14c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5538173
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93907}
We only need to save/restore pending messages when we're catching and rethrowning an exception, so push the code to paths that handle CMD_RETHROW. (We always pass through RETHROW if we caught since we might rethrow. This could be overwritten later of course, in which case we won't restore.)
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/5529233 with a test for the blocking failure. The fix is to avoid reusing the register between the context that's stashed for the `try` and the `message`. Otherwise in loops with a finally that exit the loop through the rethrow path, sloppy tracking of loop assignments thinks the context cache is assigned (by the reused message); causing a loop phi to be created.
A possible cleaner solution is to not store the context at runtime at all, and to recompute the context. However, our optimizing compilers also rely on the interpreter stashing the context on the side for `catch`, so it's not trivial to change this.
Change-Id: I2a75a248ad252e30540268b575be0fe1380c097f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5534748
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93866}
We only need to save/restore pending messages when we're catching and rethrowning an exception, so push the code to paths that handle CMD_RETHROW. (We always pass through RETHROW if we caught since we might rethrow. This could be overwritten later of course, in which case we won't restore.)
Change-Id: Ic476c99747077e316b306a5d760d6fb13ae85899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5529233
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93817}
This allows us to ignore the catch block for optimization across it.
Better would be to lazy deopt code that throws if the target catch
handler wasn't generated. I'll look into that next.
Bug: v8:7700
Change-Id: Ibeac8995571a339cf88e9302011fff60caaa2fdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5498885
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93687}
On a microbenchmark
```for (let i = 0; i < ...; i++) r += i```
when I ended up getting a gap-mov double->double for r it was 20% slower
with mov.d instead of mov.q, probably because the size doesn't match the
fadd size.
Change-Id: Ida5de7bb698cfe893a75f1d1ffe348405d6ae670
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5272483
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92217}
... when transitioning between different representations of the same
property while creating different instances (e.g. from a heap integer
to a SMI).
Bug: chromium:1499222
Change-Id: I783f0690941040863bbff84dc9f10334c17f3bd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5235437
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91996}
With context-specific meta-maps we have a cheap way of accessing the
creation context, so we can use that instead. This aligns the embedder
field location for global proxies with regular objects.
Change-Id: I74cff477cd8d76903251db41e5aefe67ace1d00f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5135175
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91928}
Only use InternalEscapableScope internally, and specialize it to not
support Escape(Local<T>()) anymore.
Drop runtime check for double-escaping values. Make it a DCHECK instead.
Change-Id: Id186296c5226a54b44c4fc489d6eac395c988e42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5144990
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91622}
This breaks array-buffer key checking on failure (will crash on throw)
but unfortunately some embedders already don't enter before detaching so
they would possibly be broken in that case. Presumably they know what
buffers they are handling...
Change-Id: Ie17a472cf6dfe5fc4ff6de3345ad7bb6fc7e8ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5095096
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91380}
The difference wasn't very well understood, and actually leads to
wonky/broken semantics.
Scheduled exceptions were embedder-side exceptions, while pending
exceptions were used inside of v8. Conversions were done on the
boundaries. Pending exceptions could be cleared locally without
try/catch since we'd only propagate exceptions to external try/catch on
Promotion. An embedder-side TryCatch could be reused without
v8::TryCatch::Reset() first. If there already was an exception and a new
one was thrown, the exception was simply overwritten.
Or that was the theory.
V8 is reentrant. When the embedder returns to V8 a scheduled exception
had to be turned into a pending exception
(Isolate::PromoteScheduledException()). When V8 returns to the embedder,
a pending exception is turned into a scheduled exception
(Isolate::OptionalRescheduleException()) to make sure that exceptions
can be returned through multiple JS/embedder stack segments.
This CL drops the distinction between scheduled and pending exceptions.
A possible pending exception is dropped on rentry in V8, meaning the
embedder will always be able to call into V8 again despite being given
an error.
This slightly changes the semantics: if an embedder calls into V8 while
a pending exception was sitting around, it won't be "rethrown" on exit
to the caller of the embedder. However, this case (rentering V8 without
an explicit TryCatch) would already have been partially broken: if V8
would call out to the embedder again, on return to V8 the exception
would have been throw there, instead of only when returning to the first
call to V8.
Embedder code may need to be fixed to account for this change. A similar
change was needed in V8 in src/d8/async-hooks-wrapper.cc: Multiple calls
to SET_HOOK_FN needed to complete before a possible exception was
propagated to the caller. The solution is to wrap the calls in TryCatch
with ReThrow.
In a follow-up I'll look into not clearing Isolate::pending_exception on
entry at all, and instead always clear it when the exception is
propagated to TryCatch (as opposed to JS). This would change DCHECKs in
V8 that guarantee that we exit V8 when we have a pending exception. I'll
support those by adding debugmode only flags.
Bug: v8:7235
Change-Id: Iff7c8fb8ff2f0bddbac0d84ce832086fba330dd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5050065
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#91288}
AllCan Read and Write are long-deprecated mechanisms for dealing with
cross-origin access. Chrome doesn't use this anymore, and other
embedders shouldn't be using it in the first place.
I'm trying to skip some steps though by directly dropping AccessControl
in various places. Presumably most embedders won't be directly affected
by this because they won't pass in those non-default values anyway.
In the CL I'm also deprecating SetAccessor which is an outdated type of
accessor. They should be replaced with SetNativeDataProperty for
internal properties that are spec'd as properties with special
behaviour, or SetAccessorProperty for properties that are visible to JS
as accessors.
Change-Id: I6c15fb436bd949d524fe7f90d2afad05358b963e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5006387
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90805}
Promise.all had a clever hack to track whether a resolve closure was
already called, but that didn't work when .allSettled needed to track
the state of a promise across both resolve and reject. Tracking was
changed to checking a hole in the values array. This CL now migrates
Promise.all to the same mechanism; avoiding the need to check the old
mechanism.
Change-Id: I501a660659804c27f16f8676f55f94953a6b089b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5000306
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#90710}
- derived constructors have implicit receiver `the hole`. They can't get
`undefined` back from the constructor. They can throw for primitive
return values.
- non-derived constructors always have an object as implicit receiver.
They don't throw for primitive return values but swap the value.
Bug: v8:7700
Change-Id: I9c07fc2cc480e9733ad6dc09be4c3366d0278bea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4679699
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88876}
With concurrent optimization it's possible we start compilation jobs
right before an iframe navigates. We may finish compilation after
navigation completes, causing likely unnecessary work to finalize the
code. Instead abort before finalization. To match this behaviour on the
optimization side, make sure we don't kick off optimization of functions
from detached contexts.
Change-Id: I81278112e5a488e621147e4d0f7d6f23b2ab0d58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4675729
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88791}
We know the closure and its outer context when we're context
specializing, so set the initial frame values to the right constants.
This allows super() to specialize to the actual constructor we're
running; and load constants for the super constructors as well in most
cases.
Bug: v8:7700
Change-Id: Ifabfd7261dd7d89e3900dc691a3ffb109d002a83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4545077
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87739}
Introduce 3 layers:
- BuildCallWithFeedback which consumes and checks feedback. It calls
BuildCall after checking. (BuildCheckValue may annotation the incoming
function node with the known function type.)
- BuildCall may specialize based on compiler-detectable values
(constants, closures allocated in the compiled function, ..), or could
call BuildGenericCall.
- BuildGenericCall that just calls whatever the target function is;
but doesn't learn through the feedback vector. Doing so could skew
invocation acounts
Function.prototype.call calls into BuildCall since it doesn't have
additional call feedback; but doing so means we avoid duplicating
optimizations already present in BuildCall.
Bug: v8:7700
Change-Id: Ia3e4d786e0c92da34a13e7a01693d872a7a6f4f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4536977
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87700}
Otherwise we get unlimited growth. Deprecated maps aren't guaranteed to
be duplicates of undeprecated maps; and if we don't count them at all,
we might end up with a lot of feedback in optimized code (+ very long
feedback to look through in polymorphic ICs)
Change-Id: I29e3bc5a7d4599ee03e9dbf37c14ce767e10d352
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4530993
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87663}
And use it to convert the result of @@hasInstance.
TryBuildBranchFor should be extended to support all the cases that
BuildBranchIfRootConstant and BuildBranchIfToBooleanTrue have,
especially handling constants and untagged representations directly.
Bug: v8:7700
Change-Id: Ibe6559c1073d2600ea1c9c50b6dfef948053f9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4531905
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87655}
- GetInternalizedString now annotates the source as string
- Pass CheckType into more nodes to avoid smi checks
- first try to convert heap numbers to indices before handling more
complex strings
Bug: v8:7700
Change-Id: I98f57a9c39ab3e53b5a5789b489a10e247288eca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4526144
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87633}
Toon Verwaest