RFR: 8261495: Shenandoah: reconsider update references memory ordering [v3]

[Zhengyu Gu]

On Wed, 10 Feb 2021 20:44:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I think I convinced myself there is a need for `memory_order_acq_rel`. I added a sketch of (counter-)example in code comments. See if that what you were concerned about?
>
> Actually, what I meant is that CAS here should use memory_order_release and load barrier needs memory_order_acquire.
> I am not sure memory_order_acq_rel is sufficient, C++ states _memory_order_acq_rel_:
> 
> A read-modify-write operation with this memory order is both an acquire operation and a release operation. No memory reads or writes in the current thread can be reordered before or after this store. All writes in other threads that release the same atomic variable are visible before the modification and **the modification is visible in other threads that acquire the same atomic variable.**
> 
> For atomic_update_oop(), leading acq is prob. unnecessary, since the oop is either evacuated by current thread or there is a safepoint in between. My concern is missing read barrier on read side, e.g. an oop is evacuated and updated by a mutator, then the second Java thread follows fwdptr and loads the oop, without a read barrier on then load, it may see incompleted/newly evacuated oop.

Ah, I missed JDK-8261495, which is counterpart of this change.  I think memory_order_release is good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2498