RFR: 8256046: Shenandoah: Mix-in NULL_PTR in non-strong ShLRBNode's type [v2]

[Aleksey Shipilev]

On Mon, 9 Nov 2020 11:29:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Testing found this problem (very rare/hard to reproduce):
>> 
>> # Internal Error (d:/a/jdk/jdk/jdk/src/hotspot/cpu/x86/macroAssembler_x86.cpp:880), pid=6160, tid=5828
>> # fatal error: DEBUG MESSAGE: unexpected null in intrinsic
>> 
>> I believe this may be caused by non-strong LRB reporting a non-NULL type by passing-through its input's type, even though it may actually return NULL on non-NULL inputs. If this serves as input to an intrinsic, it may lead to elimination of surrounding null-check, and thus end up passing a NULL to the intrinsic even thought it should not. 
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [ ] tier1+Shenandoah
>>  - [ ] tier2+Shenandoah
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Omit useless cast to oopptr

src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 2968:

> 2966:     type = type->meet(TypePtr::NULL_PTR);
> 2967:   }
> 2968:   return type;

Can probably be written as:

  if (kind() == ShenandoahBarrierSet::AccessKind::NORMAL) {
    return t2;
  }

  return t2->meet(TypePtr::NULL_PTR);

...to follow the style. Your call.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1120