RFR: JDK-8213199: GC abstraction for Assembler::needs_explicit_null_check()
erik.osterlund at oracle.com
Wed Oct 31 19:39:38 UTC 2018
Pretty sure this will break zero.
> 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:
> 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.
> Full webrev:
> Testing: passes hotspot/jtreg:tier3 on x86/fastdebug
> Can I please get reviews on this? Also, any suggestions for improvement
> are very welcome!
More information about the hotspot-gc-dev