[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