Re: [rvm-research] Recompilation and OSR

Sorry to be so late to this thread.

The optimizing compiler will do speculative inlining based on the currently loaded class hierarchy.  In effect, calls to methods that are "currently final" can be optimized as if they really were final.  To make this safe, future class loading operations go through the InvalidationDatabase to identify compiled methods that need to be invalidated because the class being loaded invalidates a CHA based optimization.  The invalid parts of these compiled methods are made unreachable & the compiled methods containing the invalid code are marked for recompilation before the class loading is allowed to complete.  

OSR is used to recover from invaldiated assumptions for compiled methods that are actually executing when the assumption is invalidated.  The code generated by the opt compiler is "prepared" for future invalidation roughly as follows.  If while compiling m1, a virtual call to m2 is found and m2 is currently final, then the compiler can inline m2 into m1 without a guard by doing:
m1() {

...code from m1....
NOP
...inlined body of m2.....
...more code from m1....
return from m1

OSRPOINT
}

In other words, several bytes of NOP instructions are put into straight-line generated code, and an unconditional OSRPOINT is placed at the end of the method.  The CFG used to optimize the program views the OSR as reachable, but it is known to not return (so it does not pollute down-stream dataflow).   In the code initially generated, there actually are no paths that reach the OSRPOINT. We get almost all of the optimization benefit of CHA (there are some costs to keeping program state live for the OSRPOINT), but can still recover if class loading invalidates the optimization.

If the InvalidationDatabase triggers an invalidation, it does two things.  First, it marks this compiled version of m1 for recompilation. Any new  invocations of m1 will go to a new compiled version (which will be created by the first such invocation).  Second, it patches the NOP instructions into an unconditional branch to the OSRPOINT.  So, any thread that is currently executing between the prologue of m1 and the entry to inlined m2 will  be redirected to the OSRPOINT.

So after a classloading event, an arbitrary number of compiled methods may be invalidated.   OSR is used to let us lazily avoid executing invalid compiled code by patching the generated code to avoid invalid paths by branching to OSR points.  All of this is prepared for in advance  by the optimizing compiler when it generated the code with the speculatively optimized code.

Hope this helps,

--dave


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers