On 08/12/2011 08:41 PM, Christian Thalinger wrote: > On Aug 12, 2011, at 8:18 PM, Tom Rodriguez wrote: > >>> Well, it's the good old: >>> >>> @ 95 java.lang.invoke.MethodHandle::invokeExact (45 bytes) size> >>> DesiredMethodLimit >>> >>> This seems to be the last recursive call that doesn't get inlined. Setting >>> MaxRecursiveInlineLevel=0 makes it go faster. I finally filed (a separate >>> bug to keep this a single change): >>> >>> 7078382: JSR 292: don't count method handle adapters against inlining >>> budgets >>> >>> The proposed fix is: >>> >>> http://cr.openjdk.java.net/~twisti/7078382/ >> I wonder if we need to be slightly more selective than this. Most method >> handle chains are relatively small and we shouldn't be penalized for that >> but they could be arbitrarily large too. Worst case they just expand into a >> bunch of call sites I guess so maybe it's not that bad. Maybe we need an >> alternate metric for this, like number of call sites in the method handle >> adapter? > Yes, using zero is not the best approach but it proved the point. Number of > call sites could be a good metric. > >> This wouldn't be so bad if method handle chains could be compiled >> separately. I suspect we're going to have to support that eventually. >> Doing that would make the performance cliff much smaller I think. > Exactly. Today I was thinking about this a lot and did some experiments. > The problem we have right now is that invokedynamic instructions have > j.l.i.MethodHandle.invokeExact as callee which is a native method. Maybe we > could store the methodOop of the method handle adapter somewhere (in the > constant pool cache?) when we have bytecode for a method handle chain and > execute that?
It can also be good to store it into the method handle (if it's possible). In that case, even a MethodHandle not linked to invokedynamic callsite can be optimized. > > -- Christian Rémi > >> tom >> >>> The numbers are now like they should be: >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server bench/bench_fib_complex.rb 5 35 >>> fib with additional calls >>> 0.865000 0.000000 0.865000 ( 0.835000) >>> 0.745000 0.000000 0.745000 ( 0.745000) >>> 0.750000 0.000000 0.750000 ( 0.750000) >>> 0.742000 0.000000 0.742000 ( 0.742000) >>> 0.743000 0.000000 0.743000 ( 0.744000) >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server >>> -Xinvokedynamic.invocation.switchpoint=true bench/bench_fib_complex.rb 5 35 >>> fib with additional calls >>> 0.789000 0.000000 0.789000 ( 0.759000) >>> 0.661000 0.000000 0.661000 ( 0.661000) >>> 0.659000 0.000000 0.659000 ( 0.660000) >>> 0.661000 0.000000 0.661000 ( 0.661000) >>> 0.661000 0.000000 0.661000 ( 0.661000) >>> >>> -- Christian >>> >>>> - 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 > _______________________________________________ > 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