RFR 8201785: Provide default implementations for ModRefBarrierSetAssembler::oop_store_at for all platforms
Aleksey Shipilev
shade at redhat.com
Wed Apr 18 10:36:00 UTC 2018
On 04/18/2018 12:30 PM, Erik Österlund wrote:
> 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.
Oh! I overlooked that BarrierSetAssembler is not abstract! Thanks, it seems to work :)
>> 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.
Okay, let me withdraw this patch, and propose the reverse: make it abstract all the way.
Thanks,
-Aleksey
More information about the hotspot-dev
mailing list