Hi Chistian, On 08/12/2011 11:44 AM, Christian Thalinger wrote: > On Aug 11, 2011, at 11:07 PM, Charles Oliver Nutter wrote: > >> On Wed, Aug 10, 2011 at 11:02 PM, Charles Oliver Nutter >> <head...@headius.com> wrote: >>> I've added bench/bench_fib_complex.rb. This runs the original fib >>> along with three variations: >>> >>> * One that uses constants for the literals 1 and 2 in the code >>> * One that dispatches to other Ruby methods for the<, -, and + calls >>> * One that does both >>> >>> Performance is perhaps most easily explained by showing the numbers: >> After talking with Christian I realized that the constant-based >> versions were not getting fully bound with invokedynamic because they >> have pre/post logic (specifically, they need to update some >> thread-local frame state in JRuby). Ignore those results for the >> moment. >> >> There does still seem to be a problem with switchpoints though. I >> stripped out all but the "additional calls" version and compared >> switchpoint invalidation with normal. >> >> >> headius@headius-desktop:~/projects/jruby$ >> JAVA_HOME=~/hsx-hotspot/build/linux/jdk-linux-i586/ bin/jruby --server >> bench/bench_fib_complex.rb 5 35 >> fib with additional calls >> 9227465 >> 2.180000 0.000000 2.180000 ( 2.070000) >> fib with additional calls >> 9227465 >> 1.829000 0.000000 1.829000 ( 1.829000) >> fib with additional calls >> 9227465 >> 1.870000 0.000000 1.870000 ( 1.870000) >> fib with additional calls >> 9227465 >> 1.642000 0.000000 1.642000 ( 1.642000) >> fib with additional calls >> 9227465 >> 1.639000 0.000000 1.639000 ( 1.639000) >> >> headius@headius-desktop:~/projects/jruby$ >> JAVA_HOME=~/hsx-hotspot/build/linux/jdk-linux-i586/ bin/jruby --server >> -Xinvokedynamic.invocation.switchpoint=true bench/bench_fib_complex.rb >> 5 35 >> fib with additional calls >> 9227465 >> 5.951000 0.000000 5.951000 ( 5.841000) >> fib with additional calls >> 9227465 >> 5.538000 0.000000 5.538000 ( 5.538000) >> fib with additional calls >> 9227465 >> 5.531000 0.000000 5.531000 ( 5.531000) >> fib with additional calls >> 9227465 >> 5.503000 0.000000 5.503000 ( 5.503000) >> fib with additional calls >> 9227465 >> 5.505000 0.000000 5.505000 ( 5.505000) >> >> My quick look through inlining shows that "plus", "minus", "lt" all >> inline into fib_ruby3 ok, as do the binops they call. fib_ruby3 >> appears to recursively inline one level. I did not see any obvious >> failures in inlining, but there's something not right here. > 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/ > > 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
I wonder if this patch is not too much. If a big method is called through an invokedynamic + method handle then it will be inlined. I wonder if it's not better to crawle the method handle tree and sum up the bytecode size of all method that have a bytecode size (all the ones that aren't in j.l.invoke). Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
