On Aug 10, 2011, at 6:21 PM, Charles Oliver Nutter wrote: > On Wed, Aug 10, 2011 at 9:26 AM, Christian Thalinger > <christian.thalin...@oracle.com> wrote: >> Here are the numbers for JDK 7 b147, 7071307+7071653, and >> 7071307+7071653+7071709: >> >> 7071307: MethodHandle bimorphic inlining should consider the frequency >> 7071653: JSR 292: call site change notification should be pushed not pulled >> 7071709: JSR 292: switchpoint invalidation should be pushed not pulled > > Yay! I have a bunch of areas I want switchpoints for :) > >> That's pretty nice but compared to non-indy it sucks: > ... >> Some assembly inspection showed that the performance difference between indy >> vs. non-indy is mostly the out-of-line calls that fall off the threshold >> cliff (10-15 call sites). When we rewrite the benchmark to loop more often >> (10M times) but only do 50 constant lookups then it gets interesting: > > Let me expand on this so I understand... > > Because there's a lot of code in the benchmarked methods, some of the > calls don't make the inlining cut. Because of that (and because of > poor degraded performance for indy + mh?), we take a bigger hit than > we gain. > > I guess my concern is that the original (long) version may or may not > inline, but obviously doesn't degrade as badly. Why does the degraded > performance of the long form suffer so much? Ruby is a very terse > language, often resulting in methods that represent a lot of code. I'm > using invokedynamic to reduce the amount of code with the assumption > that indy + mh will not count against my inlning budgets. In this > case, it appears they do?
Indeed, that's the interesting (or worrying) part. I can't answer right now why it degrades that much, I have to look at that again more closely. Today I made it to work, tomorrow I'll fix the other problems ;-) -- Christian > >> Well that's really nice! The compiler is able to optimize away all constant >> lookups because all guards in between are eliminated and it can prove that >> the constant is not used. The method is basically empty except a little >> JRuby boilerplate. Now we need a real benchmark ;-) > > Now we're talking! That's exactly what I hoped to see, and what I hope > to see if I start using SwitchPoint for other invalidation mechanisms. > This is exciting! :) > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
