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.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
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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
