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