v8/test/mjsunit/regress/regress-1034322.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

31 lines
871 B
JavaScript
Raw Normal View History

Reland "[compiler] Emit a function-entry stack check on OSR-entry" This is a reland of 8703c38d9a3e7dd49ad24ef57acf66085a768221 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}
2021-01-20 06:20:50 +00:00
// Copyright 2021 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
//
// Flags: --allow-natives-syntax --stack-size=103
let ticks = 0;
function v0() {
try { v1(); } catch {}
// This triggers the deopt that may overflow the stack.
try { undefined[null] = null; } catch {}
}
function v1() {
while (!v0()) {
// Trigger OSR early to get a crashing case asap.
if (ticks == 5) %OptimizeOsr();
Reland "[compiler] Emit a function-entry stack check on OSR-entry" This is a reland of 8703c38d9a3e7dd49ad24ef57acf66085a768221 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}
2021-01-20 06:20:50 +00:00
// With the bug fixed, there's no easy way to trigger termination. Instead,
// run until we reach a certain number of ticks. The crash triggers locally
// at tick 7562, thus running until 20k ticks to be somewhat safe.
if (ticks >= 20000) exit(0);
ticks++;
}
}
%PrepareFunctionForOptimization(v0);
%PrepareFunctionForOptimization(v1);
v0();