On Aug 12, 2011, at 8: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.
How about this: http://cr.openjdk.java.net/~twisti/7078382/ -- Christian > >> >> 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? > > -- Christian > >> >> 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
