hg: mlvm/mlvm/hotspot: indy.compiler.inline: Added generated bytecode adapters.

Charles Oliver Nutter headius at headius.com
Sun Aug 23 11:56:47 PDT 2009


On Fri, Aug 21, 2009 at 9:39 AM, Christian
Thalinger<Christian.Thalinger at sun.com> wrote:
> This commit adds generated bytecode adapters for MethodHandles.  With
> these adapters it's possible to inline the whole path of a
> MethodHandleChain, plus the ultimate target, into the caller.

Very cool :)

> But keep in mind: THIS IS WORK IN PROGRESS and is not enabled by default!

How do we enable it? It this just turning off the +testable guard?

> A lot of stuff already works, like a number of JRuby benchmarks, but
> there are also various crashes (that I actually know about).
>
> To get your whole call path inlined you may need to tweak the inlining
> thresholds a little.  To inline the call path of a simple GuardWithTest
> testcase I need to use:
>
> -XX:InlineSmallCode=1500 -XX:MaxInlineSize=50 -XX:MaxInlineLevel=15
>
> To find out what thresholds are best for you, build a debug JVM and use:
>
> -XX:+PrintCompilation -XX:+PrintInlining
>
> If you see something like:
>
>  @ 4   sun.dyn.ToGeneric$A1::invoke_I  already compiled into a medium
> method
>
> you need to increase InlineSmallCode, and for:
>
>  @ 16   java.lang.Integer::intValue  inlining too deep
>
> you, obviously, have to increase MaxInlineLevel (note: this switch is
> only available in debug builds).

Very good tips...I am now able to reproduce your perf results. I'll
post in a separate email.

> The need for this tweaking will go away in the future, but for now, if
> you want to get the whole call path inlined (which may not have the best
> performance), you have to use some switches.

Excellent...now it's starting to get really exciting :)

- Charlie


More information about the mlvm-dev mailing list