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

Aleksey Shipilev shade at openjdk.java.net
Wed Feb 10 19:07:38 UTC 2021


On Wed, 10 Feb 2021 15:25:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 149:
>> 
>>> 147:   assert(is_aligned(addr, sizeof(narrowOop)), "Address should be aligned: " PTR_FORMAT, p2i(addr));
>>> 148:   narrowOop val = CompressedOops::encode(n);
>>> 149:   return CompressedOops::decode(Atomic::cmpxchg(addr, c, val, memory_order_relaxed));
>> 
>> Are you sure it is sufficient? I would think it needs acq/rel pair, otherwise, read side can see incomplete oop ...
>
> 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?

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

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



More information about the hotspot-gc-dev mailing list