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

[Erik Österlund]

Hi Aleksey,

On 2018-04-18 12:22, Aleksey Shipilev wrote:
> 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.

The same should go for BarrierSetAssembler - you should be able to just 
instantiate a BarrierSetAssembler if you don't want to make your own 
assembler that inherits from BarrierSetAssembler.

> 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.

I think ModRefBarrierSetAssembler should be abstract on all 
architectures. It is really only a helper for GCs with a notion of write 
barriers.

Thanks,
/Erik

> Thanks,
> -Aleksey
>
>