RFR: 8248238: Implementation of JEP: Windows AArch64 Support

[Andrew Haley]

On 18/09/2020 11:14, Monica Beckwith wrote:

> This is a continuation of
> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]

It's still wrong, I'm afraid. This is not a full barrier:

+#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel);

it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as
well. It might well be that you get the same DMB ISH instruction, but
unless you use a StoreLoad barrier here it's theoretically possible
for a compiler to reorder accesses so that a processor sees its own
stores before other processors do. (And it's confusing for the reader
too.)

Use:

+#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst);

See here:

https://en.cppreference.com/w/cpp/atomic/memory_order

memory_order_seq_cst "...plus a single total order exists in which all
threads observe all modifications in the same order (see
Sequentially-consistent ordering below)"

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