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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Oct 21 21:22:27 UTC 2014


You have valid point.

When I changed the test to pass Object to testLoopOne() the NULL check 
with uncommon trap was folded into implicit NULL:

02c   	movl    R10, [RDX + #8 (8-bit)]	# compressed klass ptr
030   	NullCheck RDX
030
030   B2: #	B4 B3 <- B1  Freq: 0.999999
030   	cmpl    R10, narrowklass: precise klass java/lang/String: 
0x00007fe7ba0367e0:Constant:exact *	# compressed klass ptr
037   	jne,u  B4  P=0.000000 C=-1.000000
037

So my original statement (no load in Class.cast()) was incorrect.
With my changes it did not and it has more instructions generated.

Also checkcast is placed on exit block - it dominates following code as 
you said.

I will try intrinsic and see how it works. The problem with intrinsic we 
don't get profiling info from Class.cast() MDO. That is why I tried to 
avoid it.

Thanks,
Vladimir

On 10/21/14 2:36 AM, Roland Westrelin wrote:
>> Even if isInstance() is not folded we don't need to generate uncommon trap for obj == null case:
>>
>> if (obj != null) {
>>    if (!isInstance(obj)) {
>>       uncommon_trap(); // or throw code
>>    }
>> }
>> return obj;
>>
>> One benefit from having uncommon trap is it could be converted to implicit null check by folding it into a following memory instruction (load or store). In Class.cast() we don't have such memory instruction so we don't benefit from uncommon trap.
>
> Another benefit is that if we compile the isInstance as an exact check for a particular class, we can change the type of obj to that particular class:
>
> if (obj.klass != myklass) {
>    uncommon_trap();
> }
>
> // obj is of type myklass from here on
>
> If we don’t compile the null check as an uncommon trap we loose the exact type:
>
> if (obj != null) {
>    if (obj.klass != myklass) {
>      uncommon_trap();
>    }
>
>    // obj is of type myklass
> }
> // we don’t don’t know anything about obj’s type here
>
> Wouldn’t it be better to have an intrinsic for Class.cast where we check whether the isInstance goes away entirely and then we don’t compile the null check at all. Otherwise, we compile a null check with an uncommon trap so we can propagate an exact type forward?
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list