v8/test/mjsunit/baseline/flush-baseline-code.js

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

90 lines
2.3 KiB
JavaScript
Raw Normal View History

Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" This is a reland of ea55438a53ebba990e9dc206b148cff98838bf75. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
2021-07-19 16:40:25 +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: --expose-gc --stress-flush-code --allow-natives-syntax
Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" This is a reland of ea55438a53ebba990e9dc206b148cff98838bf75. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
2021-07-19 16:40:25 +00:00
// Flags: --baseline-batch-compilation-threshold=0 --sparkplug
// Flags: --no-always-sparkplug --lazy-feedback-allocation
// Flags: --flush-baseline-code --flush-bytecode --no-turbofan
// Flags: --no-stress-concurrent-inlining
// Flags: --no-concurrent-sparkplug
Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" This is a reland of ea55438a53ebba990e9dc206b148cff98838bf75. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
2021-07-19 16:40:25 +00:00
function HasBaselineCode(f) {
let opt_status = %GetOptimizationStatus(f);
return (opt_status & V8OptimizationStatus.kBaseline) !== 0;
}
function HasByteCode(f) {
let opt_status = %GetOptimizationStatus(f);
return (opt_status & V8OptimizationStatus.kInterpreted) !== 0;
}
var x = {b:20, c:30};
function f() {
return x.b + 10;
}
// Test bytecode gets flushed
f();
assertTrue(HasByteCode(f));
gc();
assertFalse(HasByteCode(f));
// Test baseline code and bytecode gets flushed
for (i = 1; i < 50; i++) {
f();
}
assertTrue(HasBaselineCode(f));
gc();
assertFalse(HasBaselineCode(f));
assertFalse(HasByteCode(f));
// Check bytecode isn't flushed if it's held strongly from somewhere but
// baseline code is flushed.
function f1(should_recurse) {
if (should_recurse) {
assertTrue(HasByteCode(f1));
for (i = 1; i < 50; i++) {
f1(false);
}
assertTrue(HasBaselineCode(f1));
gc();
Reland "Reland "[osr] Use the new OSR cache"" This is a reland of commit 9145388055f7f89d8c19fd944fe7612413fae182 Fixed: properly reference the ClearedValue in CSA (i.e. without the cage_base upper 32 bits). Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da38831d90576879eac92caaed2c5dc5a7b03d > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > 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@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > 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@{#80167} Bug: v8:12161,chromium:1320189 Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80306}
2022-05-02 11:11:16 +00:00
// TODO(jgruber, v8:12161): No longer true since we now always tier up to
// available Sparkplug code as early as possible. By the time we reach this
// assert, SP code is being executed and is thus alive.
// assertFalse(HasBaselineCode(f1));
// Also, the active tier is Sparkplug and not Ignition.
// assertTrue(ActiveTierIsIgnition(f1));
Reland "[sparkplug] Support bytecode / baseline code flushing with sparkplug" This is a reland of ea55438a53ebba990e9dc206b148cff98838bf75. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
2021-07-19 16:40:25 +00:00
}
return x.b + 10;
}
f1(false);
// Recurse first time so we have bytecode array on the stack that keeps
// bytecode alive.
f1(true);
// Flush bytecode
gc();
assertFalse(HasBaselineCode(f1));
assertFalse(HasByteCode(f1));
// Check baseline code and bytecode aren't flushed if baseline code is on
// stack.
function f2(should_recurse) {
if (should_recurse) {
assertTrue(HasBaselineCode(f2));
f2(false);
gc();
assertTrue(HasBaselineCode(f2));
}
return x.b + 10;
}
for (i = 1; i < 50; i++) {
f2(false);
}
assertTrue(HasBaselineCode(f2));
// Recurse with baseline code on stack
f2(true);