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

Garcia Gutierrez Miguel Alfredo miguelalfredo.garcia at epfl.ch
Tue Jul 30 05:35:16 PDT 2013

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

(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 Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland

More information about the graal-dev mailing list