JRuby/Seph/PHP.reboot/... SwitchPoint usage

[Christian Thalinger]

On Aug 10, 2011, at 6:21 PM, Charles Oliver Nutter wrote:

> On Wed, Aug 10, 2011 at 9:26 AM, Christian Thalinger
> <christian.thalinger at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev