Closed Bug 1851911 Opened 1 years ago Closed 1 years ago

Discarded IC stubs can cause bailout loops

Categories

(Core :: JavaScript Engine: JIT, defect, P1)

defect

Tracking

()

RESOLVED FIXED
119 Branch
Tracking Status
firefox119 --- fixed

People

(Reporter: iain, Assigned: iain)

References

Details

Attachments

(1 file)

Bug 1803419 is tracking bailout loops being detected in CI. Lukas Bernhard attached a testcase to that bug that triggers the bailout loop assertion intermittently, which I eventually converted to this consistent testcase:

// |jit-test| --fast-warmup; --no-threads; --blinterp-eager

function foo(o) {
  return o.x;
}

function bar(n) {
  with ({}) {}
  class C {}
  for (var i = 0; i < n; i++) {
    var c = new C();
    c.x = 0;
    foo(c);
  }
}

with ({}) {}

function triggerIonCompile() {
  for (var i = 0; i < 10; i++) {
    bar(3);
  }
}

triggerIonCompile();

// Fill up shape list
for (var i = 0; i < 6; i++) {
  bar(10);
}

// Overflow shape list, adding a new baseline IC.
bar(10);

// Discard that IC.
gc();

triggerIonCompile();

My analysis of the original testcase:

We have a class defined inside a function. The constructor for that class calls an initializer function to set the value of x. Inside the initializer, we have an InitProp IC. Because we keep defining new versions of the class, the shape of the object that we see in that IC keeps changing.

The first six shapes create separate ICs. While attaching the seventh, we trigger stub folding, creating a single IC with a GuardMultipleShapes op. At some point we transpile this to Ion. We keep adding new shapes to the GuardMultipleShapes until it hits MaxFoldedShapes (16).

New shapes keep being generated. We bail out of Ion; because the GuardMultipleShapes is full, we attach new stubs for those shapes. Eventually, we've bailed out too often, and we invalidate. Up to this point, everything is working as intended. The IC chain has new stubs in it, so we won't recompile with the same data.

Then we trigger a GC. All the shapes we've generated are dead. We remove the useless stubs. But now the only stub left is the GuardMultipleShapes stub. When we recompile, our IC hash is the same: the address of the folded stub hasn't changed, and it's once again the only stub.

I'm pulling this out into a separate bug, because we were seeing failures in CI (albeit fewer) before Jon landed his patches to remove stubs pointing to dead shapes.

Attachment #9352134 - Attachment description: Bug 1851911: Disable bailout loop assertion after purging stubs in JitScript::traceWeak r=jandem → Bug 1851911: Disable bailout loop assertion after purging stubs in JitScript::traceWeak r=jandem!
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2cbc53cb5d01 Disable bailout loop assertion after purging stubs in JitScript::traceWeak r=jandem
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/898b212df77b Disable bailout loop assertion after purging stubs in JitScript::traceWeak r=jandem
Flags: needinfo?(iireland)
Status: NEW → RESOLVED
Closed: 1 years ago
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: