MaxRecursiveInlineLevel oddity
Tom Rodriguez
tom.rodriguez at oracle.com
Thu Apr 28 10:44:36 PDT 2011
I believe there's actually a bug already filed about this. It will certainly change the results of the inlining in rare cases but it seems reasonable to may it consistent.
tom
On Apr 28, 2011, at 6:38 AM, Christian Thalinger wrote:
> While looking at JRuby performance and thus assembly code I noticed an oddity with recursive inlining:
>
> $ java -XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintInlining -XX:MaxRecursiveInlineLevel=0 fib
> VM option 'CICompilerCount=1'
> VM option '+PrintCompilation'
> VM option '+PrintInlining'
> VM option 'MaxRecursiveInlineLevel=0'
> 340 1 fib::fib (21 bytes)
> @ 10 fib::fib (21 bytes) inline (hot)
> @ 10 fib::fib (21 bytes) recursively inlining too deep
> @ 16 fib::fib (21 bytes) recursively inlining too deep
> @ 16 fib::fib (21 bytes) inline (hot)
> @ 10 fib::fib (21 bytes) recursively inlining too deep
> @ 16 fib::fib (21 bytes) recursively inlining too deep
> 362 1 % fib::main @ 2 (21 bytes)
> @ 10 fib::fib (21 bytes) inline (hot)
> @ 10 fib::fib (21 bytes) recursively inlining too deep
> @ 16 fib::fib (21 bytes) recursively inlining too deep
>
> It seems there is a "bug" in the logic in that it doesn't take the compiled method into account when counting the recursive inlining depth. I expected when using MaxRecursiveInlineLevel=0 that there is no recursive inlining at all.
>
> The simple example above shows that it might be possible that there are performance jumps between the various compiled methods as the recursive inlining depth changes.
>
> I'd like to fix that (and I already have a fix that handles direct and indirect recursion) but the question is can we fix that given the possibility that it can change performance of applications?
>
> -- Christian
More information about the hotspot-compiler-dev
mailing list