[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}
Showing
Please
register
or
sign in
to comment