RFR: 8261492: Shenandoah: reconsider forwardee accesses memory ordering [v2]

[Martin Doerr]

On Fri, 12 Feb 2021 07:26:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Do we really need to change shenandoahBarrierSetAssembler_aarch64.cpp?
>> Address dependency ensures the ordering. Or is there anything missing?
>
>> Do we really need to change shenandoahBarrierSetAssembler_aarch64.cpp?
>> Address dependency ensures the ordering. Or is there anything missing?
> 
> True, we could use address dependency for the ordering. This thing is more or less load-consume of the newly promoted object. But, I think reasoning with (stronger) acquires is more versatile for the code we do not control (C++ generally discourages using `memory_order_consume`; that is why our C++ code acquires mark word). While we control the assembler insns sequence, it seems good to match that. It does not seem worth over-relaxing the rare path: the CAS failure path under running GC.

Thanks for your reply. Yeah, I got your point regarding C++. But we use load-consume a lot in our self-made assembly code which should be ok.
I guess the shenandoahBarrierSetAssembler_aarch64.cpp part you're changing is not very perfomance sensitive?

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

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