RFR: 8273127: Shenandoah: Adopt relaxed order for update oop

[Aleksey Shipilev]

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

I think forwardee installation is better done with `acq_rel`, given that two GC threads may try to install it, and the failing thread should consume/acquire the other forwardee. Not sure the `OrderAccess::release` provides the same semantics. I have updated #2496 with more discussion and implementation.

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

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