On Sat, Jun 4, 2011 at 2:05 AM, John Rose <john.r.r...@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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
