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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 30 08:05:08 UTC 2014


Thank you, John!

I added AssertionError as you suggested.
And I added new tests for int.class.cast and null.cast.

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

Thanks,
Vladimir

On 10/29/14 11:08 PM, John Rose wrote:
> On Oct 29, 2014, at 8:54 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto: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


More information about the hotspot-compiler-dev mailing list