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

Roland Westrelin roland.westrelin at oracle.com
Tue Oct 21 09:36:13 UTC 2014


> 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