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

[Roman Kennke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181031/875ef615/signature.asc>