RFR 8201785: Provide default implementations for ModRefBarrierSetAssembler::oop_store_at for all platforms

Aleksey Shipilev shade at redhat.com
Wed Apr 18 10:22:23 UTC 2018


On 04/18/2018 12:12 PM, Erik Österlund wrote:
> Why are you instantiating a ModRefBarrierSetAssembler as opposed to a BarrierSetAssembler? ModRef is
> meant as an abstract class for GCs that have a notion of write barriers. I don't believe your GC has
> such a notion.

To answer the Epsilon-related question: in order to reduce code duplication, current implementation
tries to delegate to existing barrier sets, where possible. ModRefBSAssembler is nearly there for
interpreter GC barriers, because even though its subclasses implement write-barrier-bearing BS, its
default implementation may do nothing for write-barriers -- and it does nothing for AArch64 and PPC,
which is convenient.

This might not be a good way to implement EpsilonBS in the end -- it should probably just go for
BarrierSetAssembler::store_at -- but see how it exposes implementation desyncs today. I think
Epsilon-related questions are not so relevant in the context of this change, which syncs
arch-specific implementations.

At very least, it makes ModRefBSAssembler consistently concrete in all arches. The alternative may
be the reverse: make ModRefBSAssembler consistently abstract in all arches, but purging AArch64 and
PPC default implementations.

Thanks,
-Aleksey




More information about the hotspot-dev mailing list