RFR: 8322535: Change default AArch64 SpinPause instruction

Andrew Haley aph at openjdk.org
Fri Jan 19 08:45:28 UTC 2024


On Mon, 15 Jan 2024 16:25:08 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The Java options OnSpinWaitInst lets you choose which AArch64 instruction should be used in `SpinPause()`. Valid values are "none", "nop", "isb" and "yield". Today the default value for OnSpinWaitInst is unfortunately "none".
> 
> However some CPUs changes the default SpinPause instruction to something better if the user hasn't used the OnSpinWaitInst option. For instance if you run a Neoverse N1, N2, V1 or V2, the default SpinPause instruction will be changed to "isb". After doing some measurements on Apple's M1-M3 CPUs it also seems like "isb" is the best yielding instruction on on those CPUs.
> 
> This PR changes the default SpinPause instruction to "yield" on all AArch64 platforms except on Apple's M1, M2 and M3 CPUs on which the default value will be "isb".
> 
> Tested tier1-tier7 successfully on linux-aarch64 and macosx-aarch64.

So, if I may summarize:

Some Arm software uses ISB as a spin pause, and some claim better performance in some cases, but we have no supporting data.

At present, on Apple silicon, spin pause is a nop. Apple silicon is an in-house design, which speculates more than other AArch64 implementations, and has more to lose with an ISB. That doesn't mean that an ISB on Apple silicon is bad for the purpose, it's just that we don't know.

I was hoping that we'd have an opportunity to do some experiments on contended spin locks to try some alternatives. I was also hoping that the PR to implement spin pause on some target would be a forcing function in that direction.

YIELD, which is the instruction actually intended for this purpose, has been implemented by Arm as a nop, which is why we're looking for alternatives. WFET is another possibility.

But "do nothing" is not a neutral position, even though we have no basis on which to make a decision..

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

PR Comment: https://git.openjdk.org/jdk/pull/17430#issuecomment-1899987120


More information about the hotspot-dev mailing list