[aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read

David Holmes david.holmes at oracle.com
Thu Jul 16 22:30:20 UTC 2020

On 16/07/2020 11:43 pm, Andrew Haley wrote:
> On 16/07/2020 10:16, David Holmes wrote:
>> Seems to me that you want OrderAccess::loadload() barriers to order the
>> loads, not OrderAccess::acquire(). You should only use acquire semantics
>> to pair with a corresponding release operation.
> I agree, but it's unlikely to matter in practice.

In terms of what underlying hardware barriers get used, no it won't 
(likely) matter in practice.

But from a code understandability perspective it matters very much IMHO. 
We have been actively trying to ensure that the right OrderAccess APIs 
are used, in the right way and only where actually needed. An acquire 
without a corresponding release shows a lack of understanding and leads 
to confusion for other developers. If you need ordered loads then use a 
loadload() barrier. If the loads need to be ordered you need to ensure 
there are not corresponding writes that also need to be ordered - which 
may show where release() is missing.

> Having said that, I'm strongly of the opinion that if you see a naked
> StoreStore it may well be a bug, or at least you've got something very
> hard to analyse. I know of a few cases (e.g. zeroing an object) where
> this isn't true.
> https://www.hboehm.info/c++mm/no_write_fences.html, etc.
> But that's an argument for another day.

Indeed :)


More information about the hotspot-gc-dev mailing list