what can we expect from invokeExact()

[Rémi Forax]

About the "inlining problem",
first there is an OSR problem, the way hotspot implements OSR is broken,
when you discover that a loop is hot, instead of trying to compile
the inner-loop, the idea is to compile the method and then jump
in the middle of the inner-loop using a special supplementary entry point
generated just for that.
You will have a problem because you may have no runtime data
on the code executed after the loop, instead of generating a call to the 
interpreter
just after the loop, you have often enough information
if you just propagate the ones you gather from the analysis of the method
above the loop (more on that below), so the idea is to try to continue 
to analyze
the code until or you reach a return or you reach a branch or a call
that require runtime informations that are not available.

Now the "inlining" problem, the inner loop contains a polymorphic call
and because the method is used by a lot of different callsites
so you have a type profile pollution, i.e the method call is indeed 
magamorphic.

The idea here is to go backward.
Instead of just compiling the method, the inline algorithm should
be able to back following the stack and try to compile the caller method
and inline the method containing the hot loop. And so on
until or there is too much node, or there is no megamorphic call anymore
because the declaration of the lambda and it's call are in the same 
inlining horizon
thus can be replaced by the escape analysis.

If there is still some polymorphic calls, it's interesting to include
profiling code in the generated code to be able to gather new runtime 
profile
with less garbage because the code will be less shared.

cheers,
Rémi

On 05/07/2012 02:57 PM, Garcia Gutierrez Miguel Alfredo wrote:
> Hi,
>
> Right now the Scala compiler doesn't rely on invokedynamic but some brainstorming is underway as sketched next. Any Graal-specific insights are welcome.
>
> Two sources of slowdown for us are:
>
>    (a) "The Inlining Problem" as described by Cliff Clik [1]
>
>    (b) "datatype-agnostic bytecode" (think of arithmetic on boxed primitives and you'll be pretty close, the primitives don't change in any given invocation as they can in JavaScript, but can change across invocations)
>
> Regarding the first problem, a candidate solution involves emitting code to pass a MethodHandler object rather than a scala.Function object: the invokeExact() would hopefully be inlined , all while avoiding autoboxing (because the signature for the invokeExact() refers to primitive types if any).
>
> For (b) again MethodHandler, as described at
>    - https://groups.google.com/d/msg/jvm-languages/eEp3Z8tS8wo/KDJVFz6ZFm0J
>
> The approach "sketched" above has the HUGE HUGE HUGE advantage that no separate compilation scheme would be needed for Graal, or at most a few annotations that Graal could understand to optimize beyond what traditional HotSpot does (and yet get respectable performance from non-Graal HotSpot).
>
> Questions:
>
>    (Q1) Without hints, "inlining" a MH invokeExact() gets reduced to an invokevirtual on the target method, right? But that target method itself is not "inlined"? Or is it?
>
>    (Q2) Tracing. We've read the paper "Trace-based compilation for the Java HotSpot virtual machine" [2] and wonder how Graal goes about it (for example, regarding "The Inlining Problem")
>
> regards,
>
> Miguel
> http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded<http://lampwww.epfl.ch/%7Emagarcia/ScalaCompilerCornerReloaded>
>
>
> [1] http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem
>
> [2] Trace-based compilation for the Java HotSpot virtual machine
>      Christian Häubl, Hanspeter Mössenböck
>      http://dl.acm.org/citation.cfm?id=2093176&CFID=81110431&CFTOKEN=26096476
>
>
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/
>
>