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? -- 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
