MaxRecursiveInlineLevel oddity

[Christian Thalinger]

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