inlineMultipleMethods in Graal, and what to do with inlined bodies that become unfashionable afterwards
Garcia Gutierrez Miguel Alfredo
miguelalfredo.garcia at epfl.ch
Mon Aug 19 05:05:40 PDT 2013
After looking at about 10% of InliningPhase there's something I don't understand: what happens to inlined bodies which aren't taken ever again? (Assuming the method they were inlined into doesn't get deoptimized for other reasons).
Context for the question
------------------------
Simplifying a lot, MultiTypeGuardInlingInfo.inlineMultipleMethods() performs inlining in two ways (which affects when deoptimization gets triggered):
(a) all possible receiver-types accounted for ----> a receiver with unseen type triggers deoptimization
(b) otherwise ----> a receiver with unseen type leads to invoke-indirect
The above appears to be based on:
private boolean shouldFallbackToInvoke() {
return notRecordedTypeProbability > 0;
}
Orthogonal to that decision, either an ifs-cascade or a TypeSwitchNode is emtitted depending on:
// replace the invoke with a switch on the type of the actual receiver
boolean methodDispatch = createDispatchOnTypeBeforeInvoke(graph, successors, false, runtime);
The same question, this time in more detail
-------------------------------------------
For a callsite inlined as above (via inlineMultipleMethods) deoptimization is triggered when execution reaches a Deoptimize node (and only then). That's great.
But what about those cases where execution never astrays again into some of the method-bodies inlined thus far? (this can be seen post-JIT as if-branches or TypeSwitchNode branches never taken).
The above seems possible under both (a) and (b) above. If so, keeping dead-code (ie the branches never taken) in the StructuredGraph could prevent useful optimization from happening (max-node-size reached), besides hurting cache locality.
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/
More information about the graal-dev
mailing list