RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
Andrew Haley
aph at redhat.com
Wed Jan 22 10:52:52 UTC 2020
On 1/15/20 1:00 AM, David Holmes wrote:
> On 15/01/2020 2:15 am, Andrew Haley wrote:
>> On 1/14/20 3:52 PM, Doerr, Martin wrote:
>>
>>> good catch. I think you're right. A multi-copy-atomic, but weak
>>> architecture (e.g. aarch64) needs an instruction which orders both
>>> volatile loads.
>>
>> Good, I thought so.
>>
>> Given that TSO machines define OrderAccess::acquire() as no more than
>> a compiler barrier, I believe that we could do something like
>>
>> #ifdef CPU_MULTI_COPY_ATOMIC
>> OrderAccess::acquire();
>> #else
>> OrderAccess::fence();
>> #endif
>
> "acquire" isn't used to order loads it is used to pair with a "release"
> associated with the store of the variable now being loaded.
>
> If this is the code referred to:
>
> Age oldAge = _age.get();
> // Architectures with weak memory model require a barrier here
> // to guarantee that bottom is not older than age,
> // which is crucial for the correctness of the algorithm.
> #ifndef CPU_MULTI_COPY_ATOMIC
> OrderAccess::fence();
> #endif
> uint localBot = Atomic::load_acquire(&_bottom);
>
> then I think there is an assumption (perhaps incorrect) that the
> load_acquire will prevent reordering as well as performing the necessary
> "acquire" semantics.
It depends on how _age is written to.
As far as I can see there is no ordering between setting _bottom and setting
_age,
void set_empty() {
_bottom = 0;
_age.set(0);
}
so it looks like any kind of fence on the reader side is pointless anyway. In
that case, I don't know why we're doing any of this if it doesn't matter
what order the reader threads see updates to _age and _bottom.
It's all rather baffling. _bottom is declared volatile, as is _age, so I
guess there must be some ordering requirements, but no fences on the
writing side to enforce it.
What actually are the ordering requirements between _bottom and _age?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-gc-dev
mailing list