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

[Xiaowei Lu]

On Mon, 30 Aug 2021 16:22:22 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 believe this is fine, yet I am checking other places and running concurrency-heavy tests. The comment deserves to be updated as well, like this: https://cr.openjdk.java.net/~shade/8273127/update-comments.patch -- what do you think?

@shipilev Thanks for your suggestions. Yes, using memory order release in forwardee installation is reasonable and brings visibly performance improvement. If forwardee installation is “release”, it is incorrect to use “relaxed” in updating reference, since updating reference is possible to reorder before object copy. To fix this, I agree to your suggestion that we can use OrderAccess::release (unbounded release) to replace Atomic::cmpxchg release (bounded release). Unbounded release is enough to ensure correctness in “relaxed” updating reference, but it may result in a little bit side effect in performance, compared to bounded release. 
Besides, could we use memory_order_acq_rel in Atomic::cmpxchg of fwdptr installation? I guess this is also enough for “relaxed” updating reference, and it is more relax than memory_order_conservative by one membar on AArch64.
In short, we can 
1. use OrderAccess::release in forwardee installation and memory_order_relaxed in updating reference.
2. use memory_order_acq_rel in forwardee installation and memory_order_relaxed in updating reference.

I plan to run specjbb on both cases and see which one gives more performance boost. Looking forward to your suggestions!

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

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