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? > 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
