[Webkit-unassigned] [Bug 67826] JavaScriptCore does not have speculative->baseline OSR

Fri Sep 9 14:45:47 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=67826

Filip Pizlo <fpizlo at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #106827|0                           |1
        is obsolete|                            |

--- Comment #2 from Filip Pizlo <fpizlo at apple.com>  2011-09-09 14:45:47 PST ---
Created an attachment (id=106925)
 --> (https://bugs.webkit.org/attachment.cgi?id=106925&action=review)
work in progress - so far it appears to work, sort of

This patch still needs some love, but it's getting there!

Here's a synopsis of how this works:

1) We already had the policy of storing the bytecode index from which a DFG node originated in the node itself.  I made this policy more official by changing the name of the relevant field to CodeOrigin.  When we have inlining, the CodeOrigin class will be able to also hold the CodeBlock* from which the code originated, or more likely a pointer to an inlining stack.

2) The CodeBlock now stores a mapping between bytecode indices and machine code offsets, for each instruction, for code compiled with the old JIT.  This information is stored in using a fairly compact and fairly efficient entropy encoding, assuming that distances between adjacent indices and offsets will be small.  The DFG decodes this information when generating OSR exit code.

3) We already had the policy of emitting SetLocal nodes in the DFG flow at exactly the points where the old JIT would have mutated a virtual register.  These almost always get killed by our ref-count based DCE, but even then they remain in the IR - they're just marked dead.  This information is now used heavily by the OSR code, which performs an abstract interpretation of SetLocals in tandem with speculative compilation.  The abstract state is just a mapping between bytecode operands and the DFG nodes that hold (or held) the value that the virtual register for that bytecode operand would have held if we were executing with the old JIT.  At OSR points, we use this to figure out a strategy for recovering the value of each old JIT virtual register based on the nodes that are currently live.  In some cases, this node will be dead, which means that the old JIT would not have needed the value anyway, and so we store Undefined into the virtual register.  In other cases, there is som
 e other node that holds an equivalent value; if this is proven by the OSR recovery calculator, then that node's value is used.  In all, four cases exist: (i) the virtual register already contains the right value because the relevant SetLocal was emitted by the DFG backend, (ii) there is some physical register that contains either the value we want or a value that can be converted into the one we want, (iii) the virtual register would have held a constant at this point and we know the constant's value, or (iv) there is some other virtual register that currently holds the value that we want, so we need to shuffle the virtual register file.

4) The old JIT register allocates the result of the last operation.  Luckily, SetLocals come to the rescue once more - so the SetLocal abstract interpreter tracks the virtual register operand of the last SetLocal executed.  The OSR exit code simply loads this virtual register into the cachedResultRegister prior to jumping.

5) When all of this is enabled, we skip emitting the non-speculative code.

Work remaining:

1) Fix at least one known bug: the OSR exit code sometimes underestimates the size of the old JIT's register file (omitting temporaries that are not yet set).  Currently it does nothing for these temporaries, but it should probably set them to undefined.

2) Test, test, test.

3) Benchmark.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.