oscillating "invalidate + recompile" due to closures: myth or reality?

[Lukas Stadler]

Inlining is based on the type profile we get from HotSpot.
This tells us the first X (with X currently being 8) types and methods seen at a call site, and their probabilities.
Apart from that, it also tells us how many calls were outside these types/methods ("notRecordedProbability").

For call sites with notRecordedProbability == 0 Graal creates a deopt in the "other" case, but if notRecordedProbability > 0 is creates a real call as a fallback.
If the deopt fails it does a invalidate+reprofile, so that the profile should include the new, previously unknown type the next time the method is compiled.

We experience some recompiles from this, but overall the profiles stabilize rather quickly. We've not had problem with this so far.

- Lukas

On Jul 30, 2013, at 5:35 , Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> The good thing is that I *might* be making some progress in understanding inlining. The bad thing is that I have another question.
> 
> An object allocation conveys an exact type. Such knowledge is useful whenever a callee contains callsites on the allocated object (yes, in a previous post I asked already about a similar situation). The idea is formulated in:
> 
> Next in line, please!: exploiting the indirect benefits of inlining by accurately predicting further inlining
> A. Sewe, J. Jochem, M. Mezini
> TU Darmstadt, Germany
> http://dl.acm.org/citation.cfm?id=2095102
> 
> (for the purposes of that heuristic, a MethodHandle instance can also be regarded as determining an exact type for the host of the target method, because MHs are immutable).
> 
> (I promise I'll finally ask my question after just one more quotation, which serves as background.)
> 
> The heuristic above seems advantageous whenever our callees receive lambdas (either MHs or inner classes) because all callistes on such lambdas can be resolved to target implementations. That can only be good. My question rather is about those inlinings where the callee contains type-guarded callsites (in particular callsites on closures, whose exact type isn't known). In that case, the paper above mentions:
> 
> "If the guard test fails, dynamic dispatch is performed as a fall-back."
> 
> Question (finally!): Does that apply to code emitted by Graal? Isn't the fall-back actually a method invalidation + recompile?
> 
> (I haven't gathered any metrics, just thinking aloud)
> 
> If so, after inlining a lot of callees, it may well happen that "invalidation + recompile" oscillates a lot just because it suffices for a single type-guarded callsite to trigger another cycle of invalidation of *the whole method* followed by recompilation.
> 
> Not sure whether the sketched scenario can happen (frequently enough), comments are welcome.
> 
> 
> Miguel
> http://magarciaepfl.github.io/scala/
> 
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/