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