RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()
rkennke at redhat.com
Wed Oct 31 17:27:15 UTC 2018
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:
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:
The corresponding Shenandoah implementation for x86 would then look like
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.
Testing: passes hotspot/jtreg:tier3 on x86/fastdebug
Can I please get reviews on this? Also, any suggestions for improvement
are very welcome!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev