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

Erik Österlund erik.osterlund at oracle.com
Wed Apr 18 10:40:08 UTC 2018


Hi Aleksey,

On 2018-04-18 12:36, Aleksey Shipilev wrote:
> 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, that would be great. :)

/Erik

> Thanks,
> -Aleksey
>
>



More information about the hotspot-dev mailing list