MethodHandle lookupinvocation performance

2011-07-09 Thread Hiroshi Nakamura
Hello, I heard that jsr292 makes dynamic method lookupinvocation 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:

Auto Reply: MethodHandle lookupinvocation performance

2011-07-09 Thread bertrand . delsart
Sorry, I'm away till August 1st. For urgent matters, please contact David.Therkelsen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Jochen Theodorou
Am 09.07.2011 10:48, schrieb Hiroshi Nakamura: Hello, I heard that jsr292 makes dynamic method lookupinvocation 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:

Auto Reply: Re: MethodHandle lookupinvocation performance

2011-07-09 Thread bertrand . delsart
Sorry, I'm away till August 1st. For urgent matters, please contact David.Therkelsen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Rémi Forax
You should avoid to create constants more than once. Also, bindTo() will create a method handle for-each call. You can transform your code like that: private static final MethodHandles.Lookup lookup = MethodHandles.lookup(); private static final MethodType mt =

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Rémi Forax
On 07/09/2011 12:21 PM, Rémi Forax wrote: You should avoid to create constants more than once. Also, bindTo() will create a method handle for-each call. You can transform your code like that: private static final MethodHandles.Lookup lookup = MethodHandles.lookup(); private

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Hiroshi Nakamura
Hello, Thanks for your swift responses. On Sat, Jul 9, 2011 at 19:29, Rémi Forax fo...@univ-mlv.fr wrote: You should avoid to create constants more than once. Indeed. I updated the benckmark. (please see below) Also, bindTo() will create a method handle for-each call. Sure, but

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Hiroshi Nakamura
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

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Alexander Turner
Hi, I am Alex Turner - I was working on a COBOL to JVM compiler and am now helping with a Magik to JVM compiler. I thought I might just confirm that invokeExact has proven a lt ot quicker than invoke in our tests. We have also noticed that using a method adapter to convert argument counts makes

Auto Reply: Re: MethodHandle lookupinvocation performance

2011-07-09 Thread bertrand . delsart
Sorry, I'm away till August 1st. For urgent matters, please contact David.Therkelsen ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: MethodHandle lookupinvocation performance

2011-07-09 Thread Rémi Forax
As Jochen says, package java.lang.invoke is optimized to make invokeExact fast (especially with primitive), not lookup.findVirtual, asType, bindTo etc. The difference between reflection and method handle is when the security check occurs. lookup.findVirtual does the security check and