Is CPU_MULTI_COPY_ATOMIC the correct test here?

Andrew Haley aph at redhat.com
Tue Jan 14 14:22:30 UTC 2020


AArch64 is multi-copy atomic, but it has a relaxed memory model. I'm looking
at the CPU_MULTI_COPY_ATOMIC in this code:

template<class E, MEMFLAGS F, unsigned int N>
bool GenericTaskQueue<E, F, N>::pop_global(volatile E& t) {
  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);
  uint n_elems = size(localBot, oldAge.top());
  if (n_elems == 0) {
    return false;
  }

It seems to me that what we're asking here is not whether the CPU is
multi-copy atomic, but whether it's TSO or not. I'd like to turn
CPU_MULTI_COPY_ATOMIC off for AArch64, but I think that
GenericTaskQueue::pop_global() will break if I do.

-- 
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