« Return to Thread: Recompilation and OSR
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.
Again, I'm not 100% sure, but things are *easier* in the absence of active2. 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?
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.
« Return to Thread: Recompilation and OSR
| Free embeddable forum powered by Nabble | Forum Help |