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