MaxRecursiveInlineLevel oddity
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Apr 28 10:56:34 PDT 2011
6552561: MaxRecursiveInlineLevel flag doesn't operate correctly
Tom Rodriguez wrote:
> 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