Bug 121374 – Deoptimize deoptimization: make DFGOSRExitCompiler64.cpp more hackable

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

It used to be the case that OSR exits happened a lot, and we sometimes let them happen roughly in proportion to the number of times that a function completed successfully.  This was a long time ago - before we had good reoptimization heuristics and before we got our act together in other ways.  Now we don't OSR exit that much.  More than ~100 exits means that we reoptimize.  Hence while we want OSR exit to not be terribly slow and it still makes sense to emit JIT code for it, we don't really care if it makes great use of registers or anything like that.

But right now the OSRExitCompiler is still soooper optimized, and that makes the code hard to hack.  This makes adding new kinds of data formats, which the exit compiler must know about, rather difficult.  For example I couldn't figure out a good way of adding Int48 recoveries without either copy-pasting code or just adding a lot of confusing code paths.

So, the best thing to do is probably to rewrite the exit compiler to be a lot dumber.  The plan is to make it first dump all state into a scratch buffer (even if it's already in the stack in the right place!) and then dump back from the scratch buffer into the stack while performing the recoveries.  This will allow for example combining the code for reboxing an int that was in the stack in the right place, in the stack in the wrong place, or in a register - all of those cases will work the same now, which is pretty awesome.

[Filip Pizlo]

Created attachment 211678 [details]
this is just the start

[Filip Pizlo]

Created attachment 211681 [details]
the patch

[EFL EWS Bot]

Comment on attachment 211681 [details]
the patch

Attachment 211681 [details] did not pass efl-wk2-ews (efl-wk2):
Output: http://webkit-queues.appspot.com/results/1861597

[Filip Pizlo]

(In reply to comment #3)
> (From update of attachment 211681 [details])
> Attachment 211681 [details] did not pass efl-wk2-ews (efl-wk2):
> Output: http://webkit-queues.appspot.com/results/1861597

That's easy to fix.  Just remove the variable.

[EFL EWS Bot]

Comment on attachment 211681 [details]
the patch

Attachment 211681 [details] did not pass efl-ews (efl):
Output: http://webkit-queues.appspot.com/results/1817575

[Geoffrey Garen]

Comment on attachment 211681 [details]
the patch

r=me

[Early Warning System Bot]

Comment on attachment 211681 [details]
the patch

Attachment 211681 [details] did not pass qt-ews (qt):
Output: http://webkit-queues.appspot.com/results/1878611

[Early Warning System Bot]

Comment on attachment 211681 [details]
the patch

Attachment 211681 [details] did not pass qt-wk2-ews (qt-wk2):
Output: http://webkit-queues.appspot.com/results/1817643

[Filip Pizlo]

Created attachment 211715 [details]
patch for landing

Just checking if I fixed the build.

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/155820