RFR: 8261492: Shenandoah: reconsider forwardee accesses memory ordering [v2]
Aleksey Shipilev
shade at openjdk.java.net
Thu Feb 11 16:08:40 UTC 2021
On Thu, 11 Feb 2021 14:25:21 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Make sure to access fwdptr with acquire semantics in assembler code
>
> src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp line 58:
>
>> 56: assert(Thread::current()->is_Java_thread(), "Must be a mutator thread");
>> 57:
>> 58: markWord mark = obj->mark_acquire();
>
> Actually, I would argue that you don't need acquire here, since you don't touch anything other than mark word, so that there is no order that needs to be enforced.
It is not about the mark word itself, we access the forwardee afterwards. It is about transitive dependency: object copy stores -> forwardee installation (markword store, release) -> forwardee discovery (markword load, acquire) --> object copy access. Remember this: https://github.com/openjdk/jdk/pull/2498#discussion_r574498830
> src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp line 89:
>
>> 87: // (would be paired with acquire in forwardee accessors). Acquire on failed update
>> 88: // would get the updated object after the forwardee load.
>> 89: markWord prev_mark = obj->cas_set_mark(new_mark, old_mark, memory_order_acq_rel);
>
> Same here, CAS guarantees you to see latest mark word. memory_order_release should be sufficient here, paired with memory_order_acquire in resolve_forward barrier to ensure safe publishing the new object.
Again, not really about the mark word. The transitive load of the object from that fwdptr is what we are after.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2496
More information about the shenandoah-dev
mailing list