RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms

[David Holmes]

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. If the load_acquire doesn't prevent reordering then 
surely a loadload() barrier is what is needed.

David
-----