RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms
david.holmes at oracle.com
Wed Jan 15 01:00:55 UTC 2020
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
"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.
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. If the load_acquire doesn't prevent reordering then
surely a loadload() barrier is what is needed.
More information about the hotspot-gc-dev