8186670: Implement _onSpinWait() intrinsic for AArch64 #5562

eastig · 2021-09-17T11:26:03Z

This PR is a follow-up on the discussion “RFC: AArch64: Implementing spin pauses with ISB”.

It adds DIAGNOSTIC options OnSpinWaitInst=inst, where inst can be:

none: no implementation for spin pauses. This is the default value.
nop: use nop instruction for spin pauses.
isb: use isb instruction for spin pauses.
yield: use yield instruction for spin pauses.

And OnSpinWaitInstCount=count, where count specifies a number of OnSpinWaitInst and can be in 1..99 range. It is an error to use OnSpinWaitInstCount when OnSpinWaitInst is none.

The code for the Thread.onSpinWait intrinsic is generated based on the values of OnSpinWaitInst and OnSpinWaitInstCount.

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

CSR: https://bugs.openjdk.java.net/browse/JDK-8274564

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8186670: Implement _onSpinWait() intrinsic for AArch64

Reviewers

Paul Hohensee (@phohensee - Reviewer) ⚠️ Review applies to d4a5183
Andrew Haley (@theRealAph - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5562/head:pull/5562
$ git checkout pull/5562

Update a local copy of the PR:
$ git checkout pull/5562
$ git pull https://git.openjdk.java.net/jdk pull/5562/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5562

View PR using the GUI difftool:
$ git pr show -t 5562

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5562.diff

bridgekeeper · 2021-09-17T11:27:22Z

👋 Welcome back eastig! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-09-17T11:31:03Z

@eastig The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-09-17T11:36:10Z

Webrevs

stooart-mon

Looks Ok to me, this is the most future proof option.
Will you be adding code to set the default depending on model, or is that something for your fork?

stooart-mon · 2021-09-17T16:44:27Z

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp

-  Unimplemented();
+  switch (VM_Version::pause_impl_desc().inst()) {
+    case NOP:
+      for (unsigned int i = 1; i < VM_Version::pause_impl_desc().inst_count(); ++i) {


Shouldn't these loops be indexed from 0?

Good catch. It is a copy-paste error.
Is there any method to test C1 generated assembly code?

You could do it the same way as hotspot/jtreg/compiler/c2/aarch64/TestVolatiles.java, i.e. spawn a subtask and parse the output dump. It's very fiddly, though.

Yes, I used it as an example when I was writing tests for the PR. It works only for C2 because it relies on C2 XX:+PrintOptoAssembly. I haven't found anything similar for C1.

-XX:+PrintAssembly

To have assembly instructions in -XX:+PrintAssembly output hsdis needs to be provided:

0x0000ffff61ba2b5c: ; {metadata({method} {0x0000000800466ab8} 'isLatin1' '()Z' in 'java/lang/String')} 0x0000ffff61ba2b5c: 0857 8dd2 | c808 a0f2 | 0801 c0f2 | e807 00f9 ;; 0xFFFFFFFFFFFFFFFF 0x0000ffff61ba2b6c: 0800 8092 | e803 00f9 0x0000ffff61ba2b74: ; {runtime_call counter_overflow Runtime1 stub}

However it can help to skip to the place where instructions are expected and to check instructions' hex code.

True. There's no C1 equivalent.

I rewrote a test to parse XX:+PrintAssembly hex instructions.

phohensee

Do you intend to make isb the default for N1?

eastig · 2021-09-17T20:13:38Z

Do you intend to make isb the default for N1?

Yes, I do.
I'll rewrite #5112 to use different implementations.
After that, I'd like to enable ISB for N1.

src/hotspot/cpu/aarch64/aarch64.ad

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp

dholmes-ora · 2021-09-19T13:07:22Z

/csr needed

dholmes-ora · 2021-09-19T13:07:49Z

If you are adding a new product flag then a CSR request is needed.

David

openjdk · 2021-09-20T01:23:30Z

@dholmes-ora has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@eastig please create a CSR request for issue JDK-8186670. This pull request cannot be integrated until the CSR request is approved.

theRealAph · 2021-09-21T08:03:13Z

src/hotspot/cpu/aarch64/aarch64.ad

+    switch (VM_Version::pause_impl_desc().inst()) {
+      case NOP:
+        PRINT_N_INST(nop)
+        break;
+      case ISB:
+        PRINT_N_INST(isb)
+        break;
+      case YIELD:
+        PRINT_N_INST(yield)
+        break;
+      default:
+        ShouldNotReachHere();
+    }
+    #undef EMIT_N_ASM_STRINGS


None of this is necessary. Printing "onspinwait" is enough.

This results no instructions implementing onspinwait in OptoAssembly output. Why do we want to hide the details?

It's not useful as a verification that the correct instructions were generated: you need a disassembly for that. OptoAssembly is usually a somewhat briefer format.

theRealAph · 2021-09-21T08:04:15Z

src/hotspot/cpu/aarch64/aarch64.ad

+    switch (VM_Version::pause_impl_desc().inst()) {
+      case NOP:
+        EMIT_N_INST(inst_count, nop);
+        break;
+      case ISB:
+        EMIT_N_INST(inst_count, isb);
+        break;
+      case YIELD:
+        EMIT_N_INST(inst_count, yield);
+        break;
+      default:
+        ShouldNotReachHere();
+    }
+  %}


Please let the MacroAssembler do this. Just call MacroAssembler::spin_wait().

theRealAph · 2021-09-21T08:05:07Z

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp

+      EMIT_N_INST(inst_count, nop);
+      break;
+    case ISB:
+      EMIT_N_INST(inst_count, isb);
+      break;
+    case YIELD:
+      EMIT_N_INST(inst_count, yield);
+      break;
+    default:
+      ShouldNotReachHere();


Same here. Please just call MacroAssembler::spin_wait().

theRealAph · 2021-09-21T08:13:03Z

src/hotspot/cpu/aarch64/globals_aarch64.hpp

@@ -110,7 +110,10 @@ define_pd_global(intx, InlineSmallCode,          1000);
  product(int, SoftwarePrefetchHintDistance, -1,                        \
          "Use prfm hint with specified distance in compiled code."     \
          "Value -1 means off.")                                        \
-          range(-1, 4096)
+          range(-1, 4096)                                               \
+  product(ccstr, UsePauseImpl, "none",                                  \


The name "UsePauseImpl" fails to make the connection with onSpinWait. If you called it something like OnSpinWaitImpl that would make the connection.

theRealAph · 2021-09-21T08:14:38Z

src/hotspot/cpu/aarch64/globals_aarch64.hpp

-          range(-1, 4096)
+          range(-1, 4096)                                               \
+  product(ccstr, UsePauseImpl, "none",                                  \
+          "Use instructions to implement pauses."                       \


Suggested change

"Use instructions to implement pauses." \

"Use instructions to implement java.lang.Thread.onSpinWait() ." \

eastig · 2021-09-21T12:40:01Z

If you are adding a new product flag then a CSR request is needed.

David

Hi David,
I'll create a CSR when the name of the option is finilazed.

Code emitting spin pauses is moved to MacroAssembler::spin_wait. As OptoAssembly output is changed, tests are updated to parse PrintAssembly.

nick-arm · 2021-09-22T03:03:02Z

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp

@@ -1380,6 +1380,27 @@ class MacroAssembler: public Assembler {
  void cache_wb(Address line);
  void cache_wbsync(bool is_pre);

+  // Code for java.lang.Thread::onSpinWait() intrinsic.
+  void spin_wait() {
+#define EMIT_N_INST(n, inst) for (int i = 0; i < (n); ++i) inst()


Why use a macro here? You could just put the loop around the switch statement. And the method body seems sufficiently large that it ought to go in the .cpp file.

Good point. There's no significant performance advantage to having this in the header.

Why use a macro here? You could just put the loop around the switch statement. And the method body seems sufficiently large that it ought to go in the .cpp file.

:) compiler engineering experience. Compilers have a problem to apply unswitching optimization to loop-invariant SWITCHes.
I'll update the code as suggested.

eastig · 2021-09-22T12:34:17Z

@theRealAph, when I was writing a test I notice a strange thing in PrintAssembly output:

# {method} {0x0000ffff6ac00370} 'test' '()V' in 'compiler/onSpinWait/TestOnSpinWaitImplAArch64$Launcher'
  #           [sp+0x40]  (sp of caller)
  0x0000ffff9d557680: 1f20 03d5 | e953 40d1 | 3f01 00f9 | ff03 01d1 | fd7b 03a9 | 1f20 03d5 | 1f20 03d5 | 1f20 03d5
  0x0000ffff9d5576a0: 1f20 03d5 | 1f20 03d5 | 1f20 03d5

  0x0000ffff9d5576ac: ;*invokestatic onSpinWait {reexecute=0 rethrow=0 return_oop=0}
                      ; - compiler.onSpinWait.TestOnSpinWaitImplAArch64$Launcher::test@0 (line 161)
  0x0000ffff9d5576ac: 1f20 03d5 | fd7b 43a9 | ff03 0191

The code is for the case when 7 NOPs are used for a spin pause.
In the output only one instruction is after invokestatic onSpinWait. Other 6 instructions are before it.
Is it expected behaviour or a bug?

In addition, comments are added to a checking method of a test.

theRealAph · 2021-09-22T13:43:02Z

It's pretty much expected, yes. The debuginfo isn't all that precise.

phohensee

In pause_aarch64.hpp, I'd put the definition of PauseInst inside the definition of PauseImplDesc in order to not clutter the global namespec more than needed.

theRealAph · 2021-09-23T08:27:01Z

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

+  } else if (strcmp(s, "yield") == 0) {
+    return PauseImplDesc(YIELD, count);
+  } else if (strcmp(s, "none") != 0) {
+    vm_exit_during_initialization("Invalid value for OnSpinWaitImpl", OnSpinWaitImpl);


Suggested change

vm_exit_during_initialization("Invalid value for OnSpinWaitImpl", OnSpinWaitImpl);

vm_exit_during_initialization("The options for OnSpinWaitImpl are nop, isb, yield, and none", OnSpinWaitImpl);

theRealAph · 2021-09-23T08:38:05Z

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp

+  if (isdigit(*s)) {
+    count = *s - '0';
+    if (count == 0) {
+      vm_exit_during_initialization("Invalid value for OnSpinWaitImpl: zero instruction count", OnSpinWaitImpl);
+    }
+    s += 1;
+  }


Suggested change

if (isdigit(*s)) {

count = *s - '0';

if (count == 0) {

vm_exit_during_initialization("Invalid value for OnSpinWaitImpl: zero instruction count", OnSpinWaitImpl);

}

s += 1;

}

while (isdigit(*s++));

count = atoi(OnSpinWaitImpl);

As far as I know, this combination of digits and named option is unusual in HotSpot; it may be unique. For the sake of not doing something so unfamiliar to our users, it may be worth separating the count and the option string.

eastig · 2021-10-15T10:08:01Z

@theRealAph, any comments on the microbenchmark I wrote?

nick-arm · 2021-10-15T10:33:22Z

@theRealAph, any comments on the microbenchmark I wrote?

I think to show the benefit of the onSpinWait() changes you'd need some contention between the threads - e.g. if nowork() was updating a shared counter.

theRealAph · 2021-10-15T13:09:27Z

@theRealAph, any comments on the microbenchmark I wrote?

Something like this works well:

   @Param({"1000000"})
    public int maxNum;

    @Param({"4"})
    public int threadCount;

    AtomicInteger theCounter;

    Thread threads[];

    void work() {
        for (;;) {
            int prev = theCounter.get();
            if (prev >= maxNum) {
                break;
            }
            if (theCounter.compareAndExchange(prev, prev + 1) != prev) {
                Thread.onSpinWait();
            }
        }
    }

    @Setup(Level.Trial)
    public void foo() {
        theCounter = new AtomicInteger();
    }

    @Setup(Level.Invocation)
    public void setup() {
        theCounter.set(0);
        threads = new Thread[threadCount];

        for (int i = 0; i< threads.length; i++) {
            threads[i] = new Thread(this::work);
        }

    }

    @Benchmark
    public void trial() throws Exception {
        for (int i = 0; i< threads.length; i++) {
            threads[i].start();
        }
        for (int i = 0; i< threads.length; i++) {
            threads[i].join();
        }
    }
}

Before:

Benchmark               (maxNum)  (threadCount)  Mode  Cnt   Score    Error  Units
ThreadOnSpinWait.trial   1000000              2  avgt    3  43.830 ± 32.543  ms/op

With -XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=4

Benchmark               (maxNum)  (threadCount)  Mode  Cnt   Score    Error  Units
ThreadOnSpinWait.trial   1000000              2  avgt    3  22.181 ± 11.592  ms/op

With -XX:OnSpinWaitInst=isb -XX:OnSpinWaitInstCount=1

Benchmark               (maxNum)  (threadCount)  Mode  Cnt   Score    Error  Units
ThreadOnSpinWait.trial   1000000              2  avgt    3  36.281 ± 31.700  ms/op

This is Apple M1, where you have to be very careful because there's some processor
frequency scaling going on.

ThreadOnSpinWait: latency of Thread.onSpinWait() vs Thread.sleep(0) vs no pause. ThreadOnSpinWaitProducerConsumer: producer-consumer where consumer can go to 1ms sleep. ThreadOnSpinWaitSharedCounter: threads racing to count up (code provided by Andrew Haley, Red Hat).

eastig · 2021-10-18T16:12:31Z

@theRealAph, any comments on the microbenchmark I wrote?

Something like this works well:

Thank you for the microbenchmark. I added it.
I also added a microbenchmark to measure the latency of Thread.onSpinWait vs Thread.sleep(0) vs no pause.
And a microbenchmark ThreadOnSpinWaitProducerConsumer.

eastig · 2021-10-20T11:01:36Z

Hi @theRealAph,
Any comments on the microbenchmarks?

theRealAph · 2021-10-20T16:16:45Z

test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java

+@OutputTimeUnit(TimeUnit.MILLISECONDS)
+@State(Scope.Benchmark)
+public class ThreadOnSpinWaitProducerConsumer {
+    @Param({"100"})


This test seems rather artificial and unrealistic to me. You can get improved performance simply by increasing the spinNum so that it waits for longer. The way to get some advantage from onSpinWait is to have multiple threads racing to update the same thing, e.g. to acquire a lock.

I agree with you. I am removing it.

@theRealAph, done

Looks good. I'm not entirely sure whether this test is truly representative of the real-world cases that people have seen, but if we find out more we can always add another JMH test.

This test is too artificial. Going through my records I've found I have a microbenchmark for java.util.concurrent. SynchronousQueue which shows good improvements on jdk11. SynchronousQueue uses onSpinWait. Since jdk17 SynchronousQueue has not been using onSpinWait any more (See https://bugs.openjdk.java.net/browse/JDK-8267502). Maybe I can come up with a microbenchmark based on SynchronousQueue code:

SNode awaitFulfill(SNode s, boolean timed, long nanos) { /* * When a node/thread is about to block, it sets its waiter * field and then rechecks state at least one more time * before actually parking, thus covering race vs * fulfiller noticing that waiter is non-null so should be * woken. * * When invoked by nodes that appear at the point of call * to be at the head of the stack, calls to park are * preceded by spins to avoid blocking when producers and * consumers are arriving very close in time. This can * happen enough to bother only on multiprocessors. * * The order of checks for returning out of main loop * reflects fact that interrupts have precedence over * normal returns, which have precedence over * timeouts. (So, on timeout, one last check for match is * done before giving up.) Except that calls from untimed * SynchronousQueue.{poll/offer} don't check interrupts * and don't wait at all, so are trapped in transfer * method rather than calling awaitFulfill. */ final long deadline = timed ? System.nanoTime() + nanos : 0L; Thread w = Thread.currentThread(); int spins = shouldSpin(s) ? (timed ? MAX_TIMED_SPINS : MAX_UNTIMED_SPINS) : 0; for (;;) { if (w.isInterrupted()) s.tryCancel(); SNode m = s.match; if (m != null) return m; if (timed) { nanos = deadline - System.nanoTime(); if (nanos <= 0L) { s.tryCancel(); continue; } } if (spins > 0) { Thread.onSpinWait(); spins = shouldSpin(s) ? (spins - 1) : 0; } else if (s.waiter == null) s.waiter = w; // establish waiter so can park next iter else if (!timed) LockSupport.park(this); else if (nanos > SPIN_FOR_TIMEOUT_THRESHOLD) LockSupport.parkNanos(this, nanos); } }

I've created https://bugs.openjdk.java.net/browse/JDK-8275728 to write such a microbenchmark.

I suggest you do https://bugs.openjdk.java.net/browse/JDK-8275728 before you commit this. A benchmark which proves that this patch has some utility is needed, isn't it?

Hi Andrew (@theRealAph),
I've created a PR: #6338 with a microbenchmark.

Hi Andrew (@theRealAph), I've created a PR: #6338 with a microbenchmark.

That's really weird. Why is the benchmark not here?

I thought a separate PR would simplify a discussion. Sorry if I was wrong.
I added it here.

eastig · 2021-11-01T12:43:19Z

Hi @theRealAph,
I see there are no other comments.
Can I proceed to integrate?

…nWait

eastig · 2021-11-11T09:40:03Z

ThreadOnSpinWaitProducerConsumer is to demonstrate Thread.onSpinWait can be used to avoid heavy locks.
The microbenchmark differs from Gil's original benchmark and Dmitry's variations. Those benchmarks produce/consume data by incrementing a volatile counter. The latency of such operations is almost zero. They also don't use heavy locks. According to Gil's SpinWaitTest.java:

This test can be used to measure and document the impact of Runtime.onSpinWait() behavior
on thread-to-thread communication latencies. E.g. when the two threads are pinned to
the two hardware threads of a shared x86 core (with a shared L1), this test will
demonstrate an estimate the best case thread-to-thread latencies possible on the
platform

Gil's microbenchmark targets SMT cases (x86 hyperthreading). As not all CPUs support SMT, the microbenchmarks cannot demonstrate benefits of Thread.onSpinWait. It is actually opposite. They show Thread.onSpinWait has negative impact on performance.

The microbenchmark from PR uses BigInteger to have 100 - 200 ns latencies for producing/consuming data. These latencies can cause either a producer or a consumer to wait each another. Waiting is implemented with Object.wait/Object.notify which are heavy. Thread.onSpinWait can be used in a spin loop to avoid them.

ARM64 results:

No spin loop

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt     Score    Error  Units
ThreadOnSpinWaitProducerConsumer.trial       100          0  avgt   75  1520.448 ± 40.507  us/op

No Thread.onSpinWait intrinsic

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt     Score    Error  Units
ThreadOnSpinWaitProducerConsumer.trial       100        125  avgt   75  1580.756 ± 47.501  us/op

ISB-based Thread.onSpinWait intrinsic

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt    Score     Error  Units
ThreadOnSpinWaitProducerConsumer.trial       100        125  avgt   75  617.454 ± 174.431  us/op

X86_64 results:

No spin loop

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt    Score     Error  Units
ThreadOnSpinWaitProducerConsumer.trial      100        125  avgt   75  1417.944 ± 1.691  us/op

No Thread.onSpinWait intrinsic

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt    Score     Error  Units
ThreadOnSpinWaitProducerConsumer.trial      100        125  avgt   75  1410.987 ± 2.093  us/op

PAUSE-based Thread.onSpinWait intrinsic

Benchmark                               (maxNum)  (spinNum)  Mode  Cnt    Score     Error  Units
ThreadOnSpinWaitProducerConsumer.trial      100        125  avgt   75  217.054 ± 1.283  us/op

theRealAph · 2021-11-11T11:35:17Z

I'm getting this for -XX:OnSpinWaitInst=yield on Apple M1:

Benchmark                                (maxNum)  (spinNum)    Score   Error  Units
ThreadOnSpinWaitProducerConsumer.trial       100        125   355.686 ± 1.263  us/op

This for -XX:OnSpinWaitInst=none:

ThreadOnSpinWaitProducerConsumer.trial       100        125   359.635 ± 0.912  us/op

This for -XX:OnSpinWaitInst=isb:

ThreadOnSpinWaitProducerConsumer.trial       100        125   169.353 ± 3.932  us/op

Which looks pretty convincing, at least for this benchmark.

I'm a bit concerned that it took so much effort to find a convincing benchmark, but I note that OnSpinWaitInst=isb doesn't seem to make anything worse, so OK.

eastig · 2021-11-11T11:59:38Z

I'm a bit concerned that it took so much effort to find a convincing benchmark, but I note that OnSpinWaitInst=isb doesn't seem to make anything worse, so OK.

Thank you Andrew.
It took the time to study the current use cases of Thread.onSpinWait why they got performance improved or did not. As usual when you have written something simple you need to check it is correct. All of these took most of the time.

eastig · 2021-11-11T12:00:35Z

/integrate

openjdk · 2021-11-11T19:39:31Z

@eastig
Your change (at version 0d6fc3f) is now ready to be sponsored by a Committer.

phohensee · 2021-11-11T22:22:03Z

/sponsor

openjdk · 2021-11-11T22:23:46Z

Going to push as commit 6954b98.
Since your change was applied there have been 725 commits pushed to the master branch:

3445e50: 8276265: jcmd man page is outdated
0ca0acf: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges
b0d7a9d: 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp
8aae88b: 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out"
6f35eed: 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails
5e98f99: 8276800: Fix table headers in NumericShaper.html
2ca4ff8: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI
c29cab8: 8276112: Inconsistent scalar replacement debug info at safepoints
aea0967: 8275854: C2: assert(stride_con != 0) failed: missed some peephole opt
9862cd0: 8275786: New javadoc option to add script files to generated documentation
... and 715 more: https://git.openjdk.java.net/jdk/compare/7e92abe7a4bd2840fed19826fbff0285732f1765...master

Your commit was automatically rebased without conflicts.

openjdk · 2021-11-11T22:24:15Z

@phohensee @eastig Pushed as commit 6954b98.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

mlbridge · 2022-05-10T17:04:55Z

Mailing list message from Stuart Monteith on hotspot-dev:

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:

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.

mlbridge · 2022-05-12T08:50:54Z

Mailing list message from Andrew Haley on hotspot-dev:

On 5/10/22 18:02, Stuart Monteith wrote:

I'll be interested in hearing what people think.

This looks like a very interesting ides.

Evgeny, could you try this on some of your benchmarks?

Thanks you,

--
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

eastig added 2 commits September 16, 2021 15:22

8186670: Implement _onSpinWait() intrinsic for AArch64

b2a191f

Add missing header file

1e856de

openjdk bot added the rfr Pull request is ready for review label Sep 17, 2021

openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 17, 2021

stooart-mon reviewed Sep 17, 2021

View reviewed changes

phohensee reviewed Sep 17, 2021

View reviewed changes

theRealAph reviewed Sep 18, 2021

View reviewed changes

src/hotspot/cpu/aarch64/aarch64.ad Outdated Show resolved Hide resolved

theRealAph reviewed Sep 18, 2021

View reviewed changes

src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp Outdated Show resolved Hide resolved

openjdk bot added the csr Pull request needs approved CSR before integration label Sep 20, 2021

Replace 'for' loops with macros

c6831a3

theRealAph reviewed Sep 21, 2021

View reviewed changes

Move emitting code to MacroAssembler::spin_wait

fc55a68

Code emitting spin pauses is moved to MacroAssembler::spin_wait. As OptoAssembly output is changed, tests are updated to parse PrintAssembly.

nick-arm reviewed Sep 22, 2021

View reviewed changes

Move spin_wait in cpp file with removal of loop macro

4db361e

In addition, comments are added to a checking method of a test.

phohensee suggested changes Sep 22, 2021

View reviewed changes

theRealAph reviewed Sep 23, 2021

View reviewed changes

eastig added 2 commits October 18, 2021 15:02

Fix formatting and spelling

42f0bb6

theRealAph reviewed Oct 20, 2021

View reviewed changes

Remove ThreadOnSpinWaitProducerConsumer microbenchmark as unrealistic

a06b482

8275728: Add simple Producer/Consumer microbenchmark for Thread.onSpi…

0d6fc3f

…nWait

theRealAph approved these changes Nov 11, 2021

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Nov 11, 2021

openjdk bot closed this Nov 11, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Nov 11, 2021

eastig mentioned this pull request Nov 16, 2021

8277137: Set OnSpinWaitInst/OnSpinWaitInstCount defaults to "isb"/1 for Arm Neoverse N1 #6415

Closed

3 tasks

eastig mentioned this pull request Dec 13, 2023

8321371: SpinPause() not implemented for bsd_aarch64/macOS #16994

Closed

3 tasks

	"Use instructions to implement pauses." \
	"Use instructions to implement java.lang.Thread.onSpinWait() ." \

	vm_exit_during_initialization("Invalid value for OnSpinWaitImpl", OnSpinWaitImpl);
	vm_exit_during_initialization("The options for OnSpinWaitImpl are nop, isb, yield, and none", OnSpinWaitImpl);

8186670: Implement _onSpinWait() intrinsic for AArch64 #5562

8186670: Implement _onSpinWait() intrinsic for AArch64 #5562

Conversation

eastig commented Sep 17, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Sep 17, 2021

openjdk bot commented Sep 17, 2021

mlbridge bot commented Sep 17, 2021 • edited Loading

Webrevs

stooart-mon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

phohensee left a comment

Choose a reason for hiding this comment

eastig commented Sep 17, 2021 • edited Loading

dholmes-ora commented Sep 19, 2021

dholmes-ora commented Sep 19, 2021

openjdk bot commented Sep 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eastig commented Sep 21, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eastig commented Sep 22, 2021

theRealAph commented Sep 22, 2021

phohensee left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eastig commented Oct 15, 2021

nick-arm commented Oct 15, 2021

theRealAph commented Oct 15, 2021 • edited Loading

eastig commented Oct 18, 2021

eastig commented Oct 20, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eastig commented Nov 1, 2021

eastig commented Nov 11, 2021

theRealAph commented Nov 11, 2021

eastig commented Nov 11, 2021

eastig commented Nov 11, 2021

openjdk bot commented Nov 11, 2021

phohensee commented Nov 11, 2021

openjdk bot commented Nov 11, 2021

openjdk bot commented Nov 11, 2021

mlbridge bot commented May 10, 2022

mlbridge bot commented May 12, 2022

eastig commented Sep 17, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 17, 2021 •

edited

Loading

eastig commented Sep 17, 2021 •

edited

Loading

theRealAph commented Oct 15, 2021 •

edited

Loading