« Return to Thread: Recompilation and OSR

Re: [rvm-research] Recompilation and OSR

by Eliot Moss :: Rate this Message:

| View in Thread

On 10/2/2011 5:41 PM, Colin(Du Li) wrote:

> I'm studying recompilation and OSR part in Jikes. I have a few questions.

> 1. Does Jikes use OSR to replace code for optimization invalidation? If so,
> could you point me to the code?

I am not 100% sure what you mean. If there is an active invocation of a method
being invalidated, then Jikes RVM will use OSR to replace that method. OSR
works essentially at the bytecode level, though the specially generated method
may be optimized, like any other method, and may actually gain more benefit
since such optimization may be done in the knowledge of specific argument
values. But optimization per se is not the sort of invalidation that
necessarily requires OSR. Put another way, optimziing a method generally
conceptually is distinct from optimizing a particular active invocation of
it. That said, someone more familiar with the internals will have to clarify
whether the system connects the two.

This all unless you mean a method was optimized under an assumption later
proved false, e.g., that a class would not have subclasses and thus that
certain methods could be treated as final and not dispatched. In that case OSR
*must* be applied. This is more of a de-optimization than an optimization.

> 2. I'm not quite clear how recompilation can deal with inlining. e.g.

> m1(){
> ...
>   m2();
> ...
> }

> 1). m2 is inlined in m1 since m2 is hot.
> 2). Late on, m2 have to be recompiled since optimization invalidation. Then
> how can compiler replace the INLINED m2 code in method m1 if m1 is not
> currently being executed so that OSR cannot work?
>
> Do I express my questions clearly?

Again, I'm not 100% sure, but things are *easier* in the absence of active
invocations. You invalidate and recompile m1 precisely because of its
dependence on m2 via inlining. This could lead to m1 being compiled a
different way (not inlining m2, perhaps -- the case I mentioned is one where
in principle if m2 had been treated as final but turned out not to be, and the
compiler *might* then not inline again -- or might use guarded inlining), or
inlining the new m2, etc.

If the system can figure out that m2 is "part of" m1 in the active invocation
(OSR) case, then it can certainly do so in the no-active-invocations case.

Someone else will need to point you to the code locations in the system,
however.

Regards -- Eliot Moss

------------------------------------------------------------------------------
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

 « Return to Thread: Recompilation and OSR