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

[Xiaowei Lu]

On Thu, 2 Sep 2021 16:28:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @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.
>
>> It seems `OrderAccess::release` performs better than `acq_rel`.
> 
> Interesting result, thanks. I think that's because on current ARM 8.2 `acq_rel` is effectively `seq_cst`, which is stronger than `release`. ARM 8.3 introduces the RCpc atomics that are weaker, but we are not there yet. Anyhow, in #2496, I tried to do the acquire conditionally now, leaving only `release` CAS to hopefully avoid this pitfall.
> 
> I also think that PR now subsumes this one: it does conditionally relaxed heap updates, while leaving "release" for self-healing paths that might run concurrently during evacuation. Would you mind testing #2496 instead? Maybe also #2496 + `OrderAccess::release` variant to see if we even need it now performance-wise? If you agree, I would suggest closing this PR and moving the rest of the work under #2496.

@shipilev Sure, let's discuss under https://github.com/openjdk/jdk/pull/2496 and I will try testing its performance. Thanks for your suggestions.

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

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