RFR: 8321371: SpinPause() not implemented for bsd_aarch64/macOS

[Evgeny Astigeevich]

On Thu, 14 Dec 2023 11:20:42 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> I understand. Here the discussion went something like this:
> 
> The BSD port is almost strictly a MacOSX port. The configurability is more costly on MacOSX, because of the need to call os::current_thread_enable_wx().
> 

Am I correct that in our current implementation if we call code of any generated stub we need to use `MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread));`?


> The vast majority of MacOSX users don't want to configure which SpinPause instruction to use, they want something that is good straight out of the box.

And they don't need to do. The configuration feature is for us to define the best spin pause implementation for an AArch64 CPU.
Different AArch64 CPU might need different implementations. For Neoverse CPUs and Apple M1, one ISB is good.

As I wrote if you don't choose an instruction for spin pause, you will have an empty onSpinWait intrinsic.

> 
> Since there is a dedicated instruction (yield) in the AArch64 for this use case, we ought to use it. 

`yield` first appeared in ARMv6. I think it can be considered as a legacy instruction. I don't know any currently existing ARM CPU which implements it. As it is not implemented, it is a NOP. 

> Because it's in the interest of the CPU vendor to have as good yield implementation as possible for each and every variety of the CPU.

It looks like vendors have not been interested in`yield` for 22 years since ARMv6 introduced in 2001.  Instead in Armv8.7-A and Armv9.2-A WFE/WFI with timeouts were introduced. They might allow more effective spin loops in hardware independent way. Cortex-X4, A720 and A520 support them. Implementations of Cortex-X4 are MediaTek Dimensity 9300 and Qualcomm Snapdragon 8 Gen 3. BTW, Apple M3 is ARMv8.6-A.

>  So if the user upgrades to a new CPU version, the SpinPause should still perform as good as possible, without the need to reconfigure.

We usually know ahead of a user, when a widely used CPU family gets new features useful for JVM. By the time users get a new CPU, they will get JVM supporting the new hardware features. With the current JDK Project release model, it's more likely users get them as soon as possible.

@fbredber 
I think what we have here is the XY problem. Please help me to understand what a problem you are trying to solve.

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

PR Comment: https://git.openjdk.org/jdk/pull/16994#issuecomment-1855950557
PR Comment: https://git.openjdk.org/jdk/pull/16994#issuecomment-1855952180