[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.
>
Created
https://bugs.openjdk.java.net/browse/JDK-8062543
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.
>
Yay!
Paul.
-------------- 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