inlineMultipleMethods in Graal, and what to do with inlined bodies that become unfashionable afterwards

[Garcia Gutierrez Miguel Alfredo]

> I'm not sure exactly how this could be achieved,
> likely by switching back to the profiling interpreter periodically
> and observing changes in the profile.

In the particular case of TypeSwitchNode or if-cascade branches resulting from inlineMultipleMethods, each such branch could be made responsible for setting a bit in a bit-mask associated to the enclosing method (ie as first instruction in that branch).

Periodically the bit-mask could be checked for zeroes, indicating branches not taken since the last time the mask was cleared. No need to get the interpreter involved.


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/

________________________________________
From: Lukas Stadler [lukas.stadler at jku.at]
Sent: Monday, August 19, 2013 2:24 PM
To: Garcia Gutierrez Miguel Alfredo
Cc: graal-dev at openjdk.java.net
Subject: Re: inlineMultipleMethods in Graal, and what to do with inlined bodies that become unfashionable afterwards

I guess this is a more general question - what if the application's behavior changes? Do we ever reprofile a method that doesn't get deoptimized?
Currently, no - the only case where reprofiling is triggered is when a static or dynamic assumption is invalidated, and thus the compiled code is deoptimized.

It could be very beneficial to detect phase changes in methods and recompile them, e.g., when a call site is megamorphic during startup and monomorphic afterwards.
I'm not sure exactly how this could be achieved, likely by switching back to the profiling interpreter periodically and observing changes in the profile.

If the dead branches have low probabilities then they will at least be placed out-of-line, so that they don't hurt code cache locality.
It is especially bad if they are the ones with high probabilities.

- Lukas

On Aug 19, 2013, at 2:05 PM, Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

>
> 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/