More performance explorations

[Charles Oliver Nutter]

On Sat, Jun 4, 2011 at 2:05 AM, John Rose <john.r.rose at oracle.com> wrote:
> On Jun 3, 2011, at 4:15 PM, Tom Rodriguez wrote:
>> These don't seem to be the source of the checkcasts in jruby though.  They seem to be explicitly part of the method handle chain.  For this chain:
>>
...
>>
>> we produce these bytecodes:
>>
...
>
> That looks like somebody did this:
>  MethodHandle inner = #method__0$RUBY$fib_ruby;
>  MethodHandle outer = inner.asType(inner.type().generic());
>
> In other words, wrapped a moderately typeful method in an erased method type of all-Object.
>
> The big question is who built that chain.
>
> One big answer is that pre-RF code was building such things routinely, in order to normalize signatures down to a few equivalence classes (arity only).  But post-RF code doesn't need to do that.  I found a few places in MethodHandleImpl.java where needless asType calls were issued in order to normalize signatures.  I changed those to an internal equivalent to explicitCastArgs, and pushed it.

Just to review, the recursive calls to fib_ruby definitely do not
involve any asType calls on my part, so it seems like they have to be
coming from within the MH machinery itself.

I'm standing by to test a build when you guys decide it's ready for testing.

>> Just blindly skipping checkcast method handles for interface types bring the time on fib down to 1.071000.
>
> That's promising.

The other benchmark of interest would be
bench/language/bench_method_dispatch_only.rb which does repeated
invocations of a mostly usless method (returns self, which should be
little more than an aload 2; areturn sequence). Benchmarking that
would give us a clearer picture of the overhead introduced by
invokedynamic plus the MH chain.

I will push a version that does a control loop with no invocations, so
it's easier to see the differential performance of the invocations
alone (the while loop appears to represent about 40% of each
iteration's time on my system).

- Charlie