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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 30 16:11:52 UTC 2014


Thank you, Paul

Vladimir

On 10/30/14 5:54 AM, Paul Sandoz wrote:
>
> 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.
>


More information about the hotspot-compiler-dev mailing list