AArch64: Implementing spin pauses with ISB

[Peter Kessler (Open Source)]

Why this is not also an issue for C code?  Shouldn't SpinPause() call a function from the C library, possibly a (GCC) built-in function implemented with a choice of NOP, YIELD, ISB, or whatever as appropriate on the architecture?  The original post referred to improvements in MySQL and MongoDB, neither of which is written in the Java programming language.  The Java platform intrinsic would need to pick an implementation, if calling the C library function was too time-consuming, or not time-consuming enough.

In addition to making the choice of implementation switchable, it would be good to get the default setting of that switch from vm_version_aarch64.cpp so vendors could set it appropriately for their implementations.

			... peter

On 8/27/21, 01:23, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:

    On 8/25/21 10:16 PM, Astigeevich, Evgeny wrote:

    > IMHO, we've only scratched the surface of it. The problem is not
    > well modelled by existing public benchmarks.  Yes, it is application
    > dependent at some level.  In case of Thread.onSpinWait it depends on
    > how an application implements spin loops.  Applications having spin
    > loops with several iterations would benefit from short onSpinWait
    > (this is what we've got in customers' benchmarks). Applications
    > calling onSpinWait only couple times would benefit from longer
    > onSpinWait.  "How heavy thread contention should be, what other
    > places", these are still open questions. To answer them we need to
    > detect the issues which is the problem itself.  What we currently
    > use is the trial-and-error approach.

    OK, thanks. I'm happy to approve a patch that switches NOP, PAUSE, and
    ISB.

    However, this all sounds a bit like cargo cult science to me. :-)

    Some thoughts. In a high-contention case this is related to backoff in
    transactional memory, where Dave Dice et al's TL2 (See "What really
    makes transactions faster?" uses exponential*random backoff, like
    Ethernet. The wisdom there is that you keep increasing the backoff
    until it is about half the time that parking would take, then actually
    park. That sounds intuitively reasonable.

    But we don't need to do anything more if just adding an ISB is good
    enough, at least for now. Let's do that, and see how it goes.

    -- 
    Andrew Haley  (he/him)
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671