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