On May 26, 2011, at 1:42 AM, Christian Thalinger wrote:
> Using Tom's new code doesn't make a difference since I think the meth.jar
> from John includes the reverted GWT code.
I just added a hook to test whether the GWT change matters or not. Choose
either flag setting:
java -Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true
java -Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=false
If false or missing, you get the old "reverted" logic.
This is the refreshed JAR:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/meth.jar
The code is also in the mlvm patch repo.
> A quick check on bench_string_ops.rb shows that a couple of numbers are
> better but some are worse, especially string == comparison (compare with
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002887.html):
This rings a bell: I recently had to fix the primitive unboxing logic to make
this sort of thing work correctly (compatibly with reflection):
MethodHandle iid = identity(int.class);
Object o = (p ? (Byte)(byte)1 : (Integer)2);
int x = (int) iid.asType(methodType(int.class, Object.class).invokeExact(o);
Note that simply casting to Integer and unboxing won't work. So there's a
tricky (and potentially slow) test to do in the adaptation of object arguments
to primitive formal parameters, or from object return types to primitive return
values.
If this is a problem, your assembly code might have calls to something ugly
called ValueConversions.primitiveConversion. Hopefully, it just has fast-path
code which verifies that a reference is the expected box type, and unboxes.
There is always a fast path which does this. But funny wrapper mixing (like
the Byte above) will cause the slow path to kick in.
-- John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
