[9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code

John Rose john.r.rose at oracle.com
Thu Oct 30 06:08:27 UTC 2014


On Oct 29, 2014, at 8:54 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8054492/webrev.03/

That's it, except a couple more comments on testing:

I would prefer a cast against int.class (more useful than int[].class).  It should get a CCE like int[], but exercise a different path through the optimizer.  So:

-187             asink = int[].class.cast(s);
+187.1         asink = int.class.cast(s);
+187.2         throw new AssertionError("not reached");
 188         } catch (ClassCastException t) {
 189             // Ignore ClassCastException: Cannot cast java.lang.String to [I

The assertion error can go in spots where an exception is expected, just to make sure the JIT doesn't allow the cast by accident.

Thanks!
— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141029/bb43216b/attachment.html>


More information about the hotspot-compiler-dev mailing list