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

[Xiaowei Lu]

On Tue, 7 Sep 2021 08:33:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.
>
>> @shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.
> 
> Thanks for testing. So explicit barrier does seem to result in a slight bump in critical-jOPS.
> 
> I assume "base" results are this PR? If so, do you have performance results for the current master? In other words, it would be interesting to see three results: baseline (current master), this PR, and this PR + `OrderAccess::release()`.

@shipilev Yes, “base” means this PR in my previous comment. Here is the result of the current master(i.e. revert all commits in this PR). It seems master performs better, so the cost of “acquire” may be really high as you have said.

master_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 23053
master_2:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 30017, critical-jOPS = 23092
master_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22383

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

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