On 07/11/2011 03:34 PM, Hervé Girod wrote: > 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?
Yes ! Rémi > 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
