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

[Xiaowei Lu]

On Tue, 31 Aug 2021 13:27:18 GMT, Aleksey Shipilev <shade 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.

@shipilev Here is the specjbb2015 result. opt1 is `acq_rel`, opt2 is `OrderAccess::release`

baseline_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31247, max-jOPS = 30168, critical-jOPS = 20319
baseline_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 20986
baseline_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21053
opt1_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29140, critical-jOPS = 16247
opt1_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29140, critical-jOPS = 18131
opt1_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29483, critical-jOPS = 15928
opt2_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32788, max-jOPS = 30168, critical-jOPS = 22622
opt2_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22462
opt2_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 33186, max-jOPS = 30168, critical-jOPS = 22845

It seems `OrderAccess::release` performs better than `acq_rel`.
I notice that you have implemented `acquire` in getting forwardee in https://github.com/openjdk/jdk/pull/2496/, so I guess the `acq` here in `acq_rel` of forwardee installation is redundant? Given the specjbb result, I prefer to use `OrderAccess::release` here in forwardee installation. It only serves as storestore barrier on AArch64 and it doesn't provide the same semantics as you have mentioned above about consume/acquire the other forwardee.

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

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