Is CPU_MULTI_COPY_ATOMIC the correct test here?
Zhengyu Gu
zgu at redhat.com
Tue Jan 14 14:37:18 UTC 2020
Hi Andrew,
Here is the discussion on this particular issue ...
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/034900.html
-Zhengyu
On 1/14/20 9:22 AM, Andrew Haley wrote:
> 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.
>
More information about the hotspot-gc-dev
mailing list