Good news, bad news

[John Rose]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110526/467e18a8/attachment-0001.html