Projects, which use JSR292

[Christian Thalinger]

On Feb 21, 2011, at 4:33 PM, Christian Thalinger wrote:
> 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

I fixed that but it didn't change performance.  I just tried bench_tak and there is still a regression.  I will look at that next.

-- Christian

> , but at least we don't inline it:
> 
>  @ 20   bench.bench_fib_recursive::method__0$RUBY$fib_ruby  recursively inlining too deep