Subject: MethodHandle lookup&invocation performance -
msg#00037

Previous Message by Date:

Re: where are our performance bottlenecks?

On Jul 7, 2011, at 8:52 AM, Christian Thalinger wrote: > On Jul 6, 2011, at 10:49 PM, Tom Rodriguez wrote: >> >> On Jul 6, 2011, at 4:18 AM, Christian Thalinger wrote: >> >>> On Jul 5, 2011, at 6:39 PM, Charles Oliver Nutter wrote: >>>> I'm not in position at this exact moment to report perf issues, but >>>> Rémi's list would be a good start. I'll return to JRuby benchmarks and >>>> start looking for specific bottlenecks. >>> >>> OK. >>> >>>> >>>> As reported in some of my my previous emails, JRuby has several uses >>>> of indy that are off by default, so it will be nice to start getting >>>> them enabled. >>> >>> When I use -Xinvokedynamic.all=true with bench_string_ops.rb I get: >>> >>> InvokeDynamicSupport.java:710:in `fixnum_op_mul': >>> java.lang.ClassCastException: org.jruby.RubyString cannot be cast to >>> org.jruby.RubyFixnum >>> >>> I just saw a benchmark I haven't seen before: bench_avi_base64.rb >>> >>> Performance with indy is not very good: >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server -Xcompile.invokedynamic=false >>> bench/bench_avi_base64.rb >>> 1.569000 0.000000 1.569000 ( 1.539000) >>> 0.895000 0.000000 0.895000 ( 0.895000) >>> 0.850000 0.000000 0.850000 ( 0.850000) >>> 0.848000 0.000000 0.848000 ( 0.848000) >>> 0.848000 0.000000 0.848000 ( 0.848000) >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server bench/bench_avi_base64.rb >>> 2.335000 0.000000 2.335000 ( 2.305000) >>> 1.503000 0.000000 1.503000 ( 1.503000) >>> 1.470000 0.000000 1.470000 ( 1.470000) >>> 1.479000 0.000000 1.479000 ( 1.479000) >>> 1.470000 0.000000 1.470000 ( 1.470000) >>> >>> The pattern I always see when I look at the inlining tree of a badly >>> performing benchmark is this one: >>> >>> @ 9 >>> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::invocationFallback >>> (197 bytes) inline (hot) >> >> I would think we don't want this inlined since it's the fallback path. Try >> -XX:CompileCommand=dontinline,*,invocationFallback. Inlining it may cause >> us to run up against other limits like the NodeInliningCutoff and >> DesiredMethodLimit. > > Ahh, right. This is inlined because of how we promote the invocation count > of the call site into the method handle chain. Sorry, I forgot. Hmm, now I'm confused. Excluding the method from compilation helps a bit: intelsdv07:~/mlvm/jruby$ jruby --server -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_avi_base64.rb CompilerOracle: dontinline *.invocationFallback 1.941000 0.000000 1.941000 ( 1.869000) 1.081000 0.000000 1.081000 ( 1.081000) 1.045000 0.000000 1.045000 ( 1.045000) 1.040000 0.000000 1.040000 ( 1.041000) 1.044000 0.000000 1.044000 ( 1.044000) But then I tried -X+C: intelsdv07:~/mlvm/jruby$ jruby -X+C --server -Xcompile.invokedynamic=false bench/bench_avi_base64.rb 1.512000 0.000000 1.512000 ( 1.484000) 0.892000 0.000000 0.892000 ( 0.892000) 0.845000 0.000000 0.845000 ( 0.846000) 0.840000 0.000000 0.840000 ( 0.840000) 0.844000 0.000000 0.844000 ( 0.844000) intelsdv07:~/mlvm/jruby$ jruby -X+C --server -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_avi_base64.rb CompilerOracle: dontinline *.invocationFallback 1.477000 0.000000 1.477000 ( 1.447000) 0.794000 0.000000 0.794000 ( 0.794000) 0.745000 0.000000 0.745000 ( 0.745000) 0.741000 0.000000 0.741000 ( 0.741000) 0.744000 0.000000 0.744000 ( 0.744000) intelsdv07:~/mlvm/jruby$ jruby -X+C --server bench/bench_avi_base64.rb 1.642000 0.000000 1.642000 ( 1.614000) 0.808000 0.000000 0.808000 ( 0.808000) 0.767000 0.000000 0.767000 ( 0.767000) 0.763000 0.000000 0.763000 ( 0.763000) 0.769000 0.000000 0.769000 ( 0.770000) So what is -X+C actually doing? The helps states: -X+C force compilation of all scripts before they are run (except eval) But I supposed that all hot scripts are compiled in JRuby in the end anyway. Is that wrong? -- Christian _______________________________________________ mlvm-dev mailing list mlvm-dev@xxxxxxxxxxxxxxxx http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Next Message by Date:

Auto Reply: MethodHandle lookup&invocation performance

Sorry, I'm away till August 1st. For urgent matters, please contact David.Therkelsen _______________________________________________ mlvm-dev mailing list mlvm-dev@xxxxxxxxxxxxxxxx http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Previous Message by Thread:

hg: mlvm/mlvm/jdk: update before integration with hsx

Changeset: 527fde99eeaa Author: jrose Date: 2011-07-05 17:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/527fde99eeaa update before integration with hsx ! meth-argcount-6983728.patch ! meth-int-7058630.patch ! meth-test-7058651.patch ! series _______________________________________________ mlvm-dev mailing list mlvm-dev@xxxxxxxxxxxxxxxx http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Next Message by Thread:

Re: MethodHandle lookup&invocation performance

Am 09.07.2011 10:48, schrieb Hiroshi Nakamura: > Hello, > > I heard that jsr292 makes dynamic method lookup&invocation faster than > reflection so I did some performance comparison against plain > reflection. I'm sending this mail since the result looks strange to > me. > > Code is here: > https://raw.github.com/nahi/jsr292-sandbox/master/src/jp/gr/java_conf/jruby/MethodHandleTest.java lookup I don't know. I am not sure about the recent versions, I think the lookup is using the same "core" as Reflection plus additional checks. I don't expect that to be faster. It would be very nice though. The performance of the invocation cannot be meassured like you do it I think. The big pro comes from the ability to inline the method calls, but this is only present if you use the invokedynamic bytecode instruction. There is currently no way in Java to express invokedynamic. And a third point... even if there where invokedynamic used, I think in your case it would not really bring forth the real performance possibilities, since your receiver is changing all the time. But in general I must say, I would have expected the performance to be at least near Reflection as well. I mean the situation is for Reflection not all that better. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead http://blackdragsview.blogspot.com/ For Groovy programming sources visit http://groovy.codehaus.org _______________________________________________ mlvm-dev mailing list mlvm-dev@xxxxxxxxxxxxxxxx http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev