... to reduce compilation overhead on the main thread for OSR
Bug: v8:12161
Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Cr-Commit-Position: refs/heads/main@{#79188}
This is a reland of 8703c38d9a
The reland marks the new test as slow, skips all variants, and
skips all non-release modes.
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
Tbr: neis@chromium.org, solanes@chromium.org
Bug: chromium:1034322
Bug: v8:9534
Change-Id: I28a23d0cc4b14d59c3d4a5dbadd5dab3ac31d442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639753
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72183}
This reverts commit 8703c38d9a.
Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview)
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org
Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1034322
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72158}
This CL extends the smarter function-entry stack check logic (see
v8:9534) to OSR'd code. These smarter stack checks prevent
overflowing the stack during deoptimization.
The challenge for both function-entry (FE) and OSR-entry (OE) stack
checks is that there is no dedicated physical StackCheck to
deoptimize into. For more context: the physical StackCheck bytecode
was removed in crrev.com/c/1914218.
FE stack checks solve this by using a marker bailout id to signify
a deopt bytecode offset before the first bytecode.
In this CL, OE stack checks take a similar approach by using the
OSR'd loop's JumpLoop bytecode, which is conceptually immediately
before the OSR'd loop header.
When a stack overflow at an OE stack check occurs: %StackGuard
may cause a lazy deopt on return to the optimized OSR code,
causing re-execution of the JumpLoop handler in the
InterpreterEnterBytecodeAdvance builtin, ultimately continuing
execution the interpreter at the first bytecode of the OSR'd loop
header.
Bug: chromium:1034322, v8:9534
Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72153}
