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