Hello,
I heard that jsr292 makes dynamic method lookup&invocation 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:
https://raw.github.com/nahi/jsr292-sandbox/master/src/jp/gr/java_conf/j
Sorry, I'm away till August 1st.
For urgent matters, please contact David.Therkelsen
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Am 09.07.2011 10:48, schrieb Hiroshi Nakamura:
> Hello,
>
> I heard that jsr292 makes dynamic method lookup&invocation 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:
> https://
Sorry, I'm away till August 1st.
For urgent matters, please contact David.Therkelsen
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
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 = MethodType.methodType(Str
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();
> pri
Hello,
Thanks for your swift responses.
On Sat, Jul 9, 2011 at 19:29, Rémi Forax 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 'bindTo(rec).invokeExact(a
Hello,
Thanks for you comments.
On Sat, Jul 9, 2011 at 19:01, Jochen Theodorou 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 us
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 th
Sorry, I'm away till August 1st.
For urgent matters, please contact David.Therkelsen
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
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 invoke/inv
On Jul 9, 2011, at 7:13 AM, Alexander Turner wrote:
> 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 us
I'm attaching an error log for a crash that's reproducible for me with
a recent openjdk-osx-build. It may or may not be useful depending on
how far behind other fixes they are.
I thought it would be interesting for MLVM list because it's happening
in Ruby code that's been jitted by C2, and likely
FWIW, the code in question (buried inside a test suite somewhere) does
not trigger the crash on Java 6u26.
On Sun, Jul 10, 2011 at 1:42 AM, Charles Oliver Nutter
wrote:
> I'm attaching an error log for a crash that's reproducible for me with
> a recent openjdk-osx-build. It may or may not be usef
14 matches
Mail list logo
