>> 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 ;-)
One thing I we should fix is that the bytecodes of the method handle adapter shouldn't count against the DesiredMethodLimit, in the same way they don't count against the inline depth. tom > > -- 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
