829175 - IonMonkey: don't get stuck in the interpreter when off thread compilation used a bad OSR pc

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Attachment: patch

After triggering off thread compilation for a script, that script will continue to run in JM until the compilation finishes and the original OSR pc is hit.  However, if a frame for the script is kicked into the interpreter without destroying the JM/Ion code (as can happen if e.g. a down frame is invalidated) then the JM code will not be reentered and execution will get stuck in the interpreter until the OSR pc is finally hit (which may not actually happen again).  After bug 820583 this bites on a newly Ion compiled script there and tanks performance.  See bug 820583 comment 19.  This fix allows entering JM code at loop heads different from the original OSR pc.

This is a band-aid, and eventually there will need to be a mechanism to allow Ion to recover if the OSR pc it compiled for is never hit again.  This could be either recompiling the script for a different OSR pc, or recompiling the script with OSR entries at all loop heads.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 700566 [details] [diff] [review]
patch

Review of attachment 700566 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah I agree this is a bandaid. It'd be interesting to try an OSR point at every loop header, but I worry about that inhibiting optimization, and just recompiling at a new OSR point sounds simpler.

Comment 2

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9095b0b49905

Comment 3

[Brian Hackett [Laid off!]]

Backed out for v8 regressions, will look at this tomorrow.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a2d8abdc82a3

Comment 4

[Brian Hackett [Laid off!]]

Attachment: updated

Patch that doesn't fire on v8bench or kraken.  It seems like tweaking the JM vs. Ion compilation heuristics even slightly regresses v8bench, so this patch adds enough junk to make sure the heuristic behavior is unchanged here.  This means running a few thousand loop iterations on emscripten-skinning in the interpreter, but at least we don't get stuck in the interpreter.

I'm thinking now a better medical analogy is a tourniquet.  The fragility of this stuff and our tendency to get stuck in JM rather than Ion is pretty horrible, but there's no sense in trying to fix this with the baseline compiler on the horizon.

Comment 6

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/73d7a2071c7c

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/73d7a2071c7c