MethodHandle lookup&invocation performance

[Hervé Girod]

That's great then! I will try to inokedynamicize my code soon to see what I could gain ;)

Herve

Sent from my iPhone

On 11 juil. 2011, at 15:36, Rémi Forax <forax at univ-mlv.fr> wrote:

> 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.thalinger at 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<blackdrag at 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 at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev