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
