RFC onSpinWait() counter intrinsic.

Stuart Monteith stumon01 at arm.com
Tue May 10 17:02:55 UTC 2022


Hello,
        Following on from Evgeny's patch, I've been looking at an alternative way implementation of onSpinWait. It is great
that we can choose between YIELDs, NOPs and ISBs or none, but it is desirable to move away from ISB. They are not
intended to be used for delays, and their implementation would likely change in future.

There are other possible implementations with Arm V8.7 features besides what we've implemented here, but silicon is just
not there yet. I've put a patch here:

        https://github.com/stooart-mon/jdk/commit/5a973ac9c67db32c649be1c317adc2185c2568fd

This implements a delay by reading a virtualized timer and waiting for a period of time to be exceeded:

       MRS X0, CNTVCT_EL0
       ADD X0, X0, #<value>
loop: YIELD
       MRS X1, CNTVCT_EL0
       CMP X1, X0
       B.LT loop

The counter is incremented at a rate that is particular to the CPU implementation - this is held in the CNTFRQ_EL0
register. For example, an Altra may tick at 25 MHz (40ns per tick), a RaspberryPi 4b will tick at 54Mhz (18ns).

This is straightforward in Java, we can just generate the static code as is. However, other software would need to load
the delay each time.


To enable this implementation, pass options like so:

-XX:OnSpinWaitInst=counter  -XX:OnSpinWaitCounterDelay=10

One of the problems with this approach, and spinwaits in general, is knowing what the correct value should be. As the
counter frequency varies between machines, and it is not clear what the actual delay itself should be - I would expect
we'd offer a minimum value, and expect the algorithm calling the wait to adjust as necessary for its purposes. Ideally
we'd implement our spinloops in such a way that all this may be unnecessary - objectMonitor.cpp alludes to spinning
locally such as MCS.

For most systems, a delay of "2" to "15" would be a good range to test. With future revisions of the Arm ARM and some
more recent cores, the CNTFRQ register will report the counters increasing by 1 billion every second, but not
necessarily in increments of 1.

I'll be interested in hearing what people think.

BR,
        Stuart



  For the the ThreadProducerConsumer spinwait tests,


On 17/09/2021 12:36, Evgeny Astigeevich wrote:
> This PR is a follow-up on the discussion [“RFC: AArch64: Implementing spin pauses with ISB”](https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-August/054033.html).
>
> It adds the option `UsePauseImpl=value`, where `value` can be:
>
> - `none`: no implementation for spin pauses. This is the default value.
> - `Nnop`: use `nop` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `nop` instructions.
> - `Nisb`: use `isb` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `isb` instructions.
> - `Nyield`: use `yield` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `yield` instructions.
>
> The code for the `Thread.onSpinWait` intrinsic is generated based on the value of `UsePauseImpl`.
>
> Testing:
>
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make run-test TEST=hotspot/jtreg/compiler/onSpinWait`: Passed
>
> -------------
>
> Commit messages:
>   - Add missing header file
>   - 8186670: Implement _onSpinWait() intrinsic for AArch64
>
> Changes: https://git.openjdk.java.net/jdk/pull/5562/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5562&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8186670
>    Stats: 460 lines in 9 files changed: 458 ins; 0 del; 2 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/5562.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/5562/head:pull/5562
>
> PR: https://git.openjdk.java.net/jdk/pull/5562

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


More information about the hotspot-dev mailing list