Projects, which use JSR292

[Christian Thalinger]

On Feb 21, 2011, at 3:19 PM, Charles Oliver Nutter wrote:
> On Mon, Feb 21, 2011 at 8:07 AM, Christian Thalinger
> <christian.thalinger at oracle.com> wrote:
>> Alright, I know what's going wrong.  The recursive inlining logic does not recognize when recursive inlining happens like:
>> 
>> fib_ruby -> invokeExact -> fib_ruby -> ...
>> 
>> I try to add some additional logic there.
> 
> I think that makes sense. I am confused why it would be considered
> recursive at all if it's not treating it as a direct recursive
> invocation. I'd love to know how Hotspot weights various types of
> invocations...
> 
> Fixing recursive invocation may help, but it seems like somehow the
> inlining decisions affect more than just recursive calls based on my
> experiment with an intermediate call.
> 
> Here's LogCompilation -i results for the intermediate version...
> 
> https://gist.github.com/837104
> 
> So perhaps there's a priority or size-weighting issue as well? Perhaps
> indy calls are being given *too much* preference over a bunch of other
> stuff that's actually more important?

Why do you think that?

What's happening in the inlining tree above is that HotSpot's check for caller == callee does not hold since there are a couple of other frames in between (like generated method handle adapters).

With a fix in place it looks like:

http://pastebin.com/JryngMUZ

It's not completely correct since the inlining depth is wrongly calculated and so we don't inline fib_ruby up to MaxRecursiveInlineLevel, but at least we don't inline it:

  @ 20   bench.bench_fib_recursive::method__0$RUBY$fib_ruby  recursively inlining too deep

-- Christian