On Feb 21, 2011, at 3:19 PM, Charles Oliver Nutter wrote: > On Mon, Feb 21, 2011 at 8:07 AM, Christian Thalinger > <christian.thalin...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
