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

[Charles Oliver Nutter]

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?

> 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