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

Zhengyu Gu zgu at openjdk.java.net
Wed Feb 10 20:47:37 UTC 2021


On Wed, 10 Feb 2021 18:59:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Actually, I think you are right: we must ensure the cumulativity of the barriers. Let me think a bit more about it.
>
> 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.**

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

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



More information about the hotspot-gc-dev mailing list