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

Paul Sandoz paul.sandoz at oracle.com
Thu Oct 30 12:54:30 UTC 2014

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

> I hope it is the final version.
> http://cr.openjdk.java.net/~kvn/8054492/webrev.02/
> Full blown intrinsic is created for Class.cast(). It tries, first, to fold statically the code. If it can't, it calls gen_checkcast() and generate uncommon trap when the exception have to be thrown. Also if we hit uncommon trap too match it will not generate instrinsic with dynamic checks during recompilation, but it still tries to fold it statically.
> Since the intrinsic can be skipped I marked Class.cast() as force_inline method to make sure it is inlined to propagate checkcast information in compiled code.



to track the replacement of MethodHandleImpl.castReference with Class.cast.

> An additional improvement could be made to type checks in intrinsics if we use speculative types. I filed RFE:
> https://bugs.openjdk.java.net/browse/JDK-8062477
> I added new regression test and added compile_id to WB nmethod information.
> Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, performance.

I also verified it worked.

> Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents improvement.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141030/7f5ceed1/signature.asc>

More information about the hotspot-compiler-dev mailing list