Hello, My comprehension is that the lookup can be performed only once, to get the MethodHandle, and that checks are done there and not after when using the MethodHandle anymore. Am I right?
Sent from my iPhone On 11 juil. 2011, at 15:17, Christian Thalinger <christian.thalin...@oracle.com> wrote: > On Jul 9, 2011, at 3:27 PM, Hiroshi Nakamura wrote: >> Hello, >> >> Thanks for you comments. >> >> On Sat, Jul 9, 2011 at 19:01, Jochen Theodorou <blackd...@gmx.org> wrote: >>>> 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. >> >> Sure. I should have written it clearly. I heard from someone at Java >> SE 7 launch event that reflection would get faster on Java SE 7 even >> if you don't use dynamic language, so I wanted to measure the >> MethodHandle perf without invokedynamic. >> >> For invokedynamic, I did some (bogus, experimental, micro)benchmark >> with current JRuby. >> http://bit.ly/invokedynamic (Flash, Japanese) >> Please see the circle at the right edge of 5 circles. Invokedynamic >> support of JRuby is still experimental but it already outperforms >> existing optimization code for some microbenchmarks. Great job, >> Charles. > > Just a quick follow up on the tak numbers, which look really bad. The > problem here is that we inline the fallback path (a bug we know about). > Excluding that one method from inlining actually gives better numbers with > invokedynamic: > > intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server > bench/bench_tak.rb 5 > user system total real > 1.300000 0.000000 1.300000 ( 1.263000) > 1.018000 0.000000 1.018000 ( 1.018000) > 1.018000 0.000000 1.018000 ( 1.018000) > 1.027000 0.000000 1.027000 ( 1.027000) > 1.024000 0.000000 1.024000 ( 1.023000) > > intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server > -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_tak.rb 5 > CompilerOracle: dontinline *.invocationFallback > user system total real > 0.619000 0.000000 0.619000 ( 0.580000) > 0.422000 0.000000 0.422000 ( 0.422000) > 0.422000 0.000000 0.422000 ( 0.422000) > 0.422000 0.000000 0.422000 ( 0.422000) > 0.422000 0.000000 0.422000 ( 0.422000) > > intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server > -Xcompile.invokedynamic=false bench/bench_tak.rb 5 > user system total real > 0.824000 0.000000 0.824000 ( 0.788000) > 0.565000 0.000000 0.565000 ( 0.565000) > 0.565000 0.000000 0.565000 ( 0.565000) > 0.565000 0.000000 0.565000 ( 0.565000) > 0.565000 0.000000 0.565000 ( 0.565000) > > -- Christian > >> >> Disclaimer: I'm one of a JRuby committer :) >> >>> 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. >> >> Sure. JRuby's current invokedynamic code checks receiver type with the >> test for guardWithTest if I understand correctly. Invokedynamic would >> not bring perf gain for my sample MethodHandleTest, but if naive >> MethodHandle invocation is slower than reflection, invokedynamic might >> be the way I thought. >> >>> 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. >> >> Agreed. I won't expect it to Java SE 7 GA though. >> >> Regards, >> // NaHi >> _______________________________________________ >> 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
