RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()

[Erik Osterlund]

Hi Roman,

Pretty sure this will break zero.

Thanks,
/Erik

> On 31 Oct 2018, at 18:27, Roman Kennke <rkennke at redhat.com> wrote:
> 
> GCs (like Shenandoah) may emit additional loads or stores. In the case
> of Shenandoah, we emit forward pointer loads from offset -8. Those
> accesses don't match the pattern currently checked in
> Assembler::needs_explicit_null_check() which means that explicit null
> checks would be emitted for forwarding pointer loads. But we don't want
> that because we know that the base object cannot be NULL (everything
> else would be an error).
> 
> I'm proposing to put an abstraction in needs_explicit_null_check(). I am
> basically trying to solve the mess that we have in Shenandoah in this place:
> 
> https://builds.shipilev.net/patch-openjdk-shenandoah-jdk-only-shared/latest/src/hotspot/share/asm/assembler.cpp.sdiff.html
> 
> After experimenting back-and-forth with a bunch of approaches, it seems
> to be most useful and least intrusive to simply put the whole method
> under GC's control by moving its body into BarrierSetAssembler:
> 
> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/src/hotspot/share/gc/shared/barrierSetAssembler.cpp.html
> 
> The corresponding Shenandoah implementation for x86 would then look like
> this:
> 
> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.shenandoah/src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp.sdiff.html
> 
> As an additional bonus, this approach provides not only a GC-abstraction
> but also implicitely a cpu-abstraction, which helps to avoid the #ifdef
> mess that we made in that method.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8213199
> Full webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8213199/webrev.00/
> 
> Testing: passes hotspot/jtreg:tier3 on x86/fastdebug
> 
> Can I please get reviews on this? Also, any suggestions for improvement
> are very welcome!
> 
> Thanks,
> Roman
>