Re: [rvm-research] Recompilation and OSR

David P Grove wrote:

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers