CPU costs of Thread.sleep() and Thread.onSpinWait()

Question

I'm running two benchmarks in order to compare costs of Thread.sleep() and Thread.onSpinWait():

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class ThreadSleep2Benchmark {
  private final ExecutorService executor = Executors.newFixedThreadPool(1);
  volatile boolean run;

  @Param({"1", "5", "10", "50", "100"})
  long delay;

  @Setup(Level.Invocation)
  public void setUp() {
    run = true;
    startThread();
  }

  @TearDown(Level.Trial)
  public void tearDown() {
    executor.shutdown();
  }

  @Benchmark
  public int sleep() throws Exception {
    while (run) {
      Thread.sleep(1);
    }
    return hashCode();
  }

  private void startThread() {
    executor.submit(() -> {
      try {
        Thread.sleep(delay / 2);
        run = false;
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException(e);
      }
    });
  }
}

Then I run the one with Thread.onSpinWait():

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class ThreadOnSpinWaitBenchmark {
  private final ExecutorService executor = Executors.newFixedThreadPool(1);
  volatile boolean run;

  @Param({"1", "5", "10", "50", "100"})
  long delay;

  @Setup(Level.Invocation)
  public void setUp() {
    run = true;
    startThread();
  }

  @TearDown(Level.Trial)
  public void tearDown() {
    executor.shutdown();
  }

  @Benchmark
  public int onSpinWait() {
    while (run) {
      Thread.onSpinWait();
    }
    return hashCode();
  }

  private void startThread() {
    executor.submit(() -> {
      try {
        Thread.sleep(delay / 2);
        run = false;
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException(e);
      }
    });
  }
}

Both demonstrate nearly same results for delay > 1 ms:

Benchmark                             (delay)  Mode  Cnt   Score    Error  Units

ThreadOnSpinWaitBenchmark.onSpinWait        1  avgt   20   0,003 ±  0,001  ms/op
ThreadOnSpinWaitBenchmark.onSpinWait        5  avgt   20   2,459 ±  0,027  ms/op
ThreadOnSpinWaitBenchmark.onSpinWait       10  avgt   20   5,957 ±  0,064  ms/op
ThreadOnSpinWaitBenchmark.onSpinWait       50  avgt   20  27,915 ±  0,225  ms/op
ThreadOnSpinWaitBenchmark.onSpinWait      100  avgt   20  53,112 ±  0,343  ms/op

ThreadSleep2Benchmark.sleep                 1  avgt   20   1,420 ±  0,043  ms/op
ThreadSleep2Benchmark.sleep                 5  avgt   20   3,183 ±  0,099  ms/op
ThreadSleep2Benchmark.sleep                10  avgt   20   6,723 ±  0,069  ms/op
ThreadSleep2Benchmark.sleep                50  avgt   20  29,697 ±  0,307  ms/op
ThreadSleep2Benchmark.sleep               100  avgt   20  54,730 ±  0,329  ms/op

This is quite expected.

I'd like however to measure CPU load of both approaches. I know that on Linux I can use LinuxPerfNormProfiler but I'm not sure which particular metric I should take to get reliable insight.

Answer 1

onSpinWait is very different than Thread.sleep(0).

When you are working with non blocking algorithms and spinning on some variable waiting for a certain state, when that state is reached the CPU can run into a very expensive pipeline flush. This is because the instruction pipeline is filled with loads for that variable, and these can be executed out of order. So an earlier load could see a later value than a later load. This incoherent behavior is not allowed (first seeing a new value and then back to seeing an old value).

This is called a memory order violation and on the X86 this leads to a machine clear which causes the instruction pipeline to be flushed. The CPU then needs to restart from the last retired instruction and try again, and perhaps the field isn't in the right state any longer so it can start again.

To prevent running into this memory order violation, on the X86 the onSpinWait executes a PAUSE instruction. This stalls the instruction pipeline for a certain number of cycles and prevents this expensive memory order violation from happening.

Another advantage of PAUSE is that you give the hypersibling more headroom and the CPU heats up less.

For some information about recent changes in the length of the PAUSE instruction, check the following link.

Answer 2

It seems that events command line argument allows us to specify the perf events we want LinuxPerfNormProfiler to collect.

To get the list of supported perf events on Linux run perf list in a terminal: see perf wiki.

task-clock seems to be the recommended event to measure CPU load.

P.S. with LinuxPerfAsmProfiler you might even get cpu load per function.
Also you might need to make some extra work to enable full Java support in perf.

Answer 3

Given a choice between Thread.sleep() and Thread.onSpinWait(), the right choice is probably Thread.sleep().

If you already have a specific reason for using onSpinWait() – like you're doing low-level performance work – then I think it's a safe assumption that you wouldn't be asking the question to begin with, nor would you be comparing it against Thread.sleep().

If you do not have a specific reason to use onSpinWait(), then you should not use it.

---

Javadoc for Thread.onSpinWait() says:

By invoking this method within each iteration of a spin-wait loop construct, the calling thread indicates to the runtime that it is busy-waiting.

Wikipedia article for busy waiting says:

busy-waiting, busy-looping or spinning is a technique in which a process repeatedly checks to see if a condition is true, such as whether keyboard input or a lock is available

In most cases spinning is considered an anti-pattern and should be avoided, as processor time that could be used to execute a different task is instead wasted on useless activity. Spinning can be a valid strategy in certain circumstances, most notably in the implementation of spinlocks within operating systems designed to run on SMP systems.

---

Beyond either of these, there are other mechanisms available in Java for managing interactions between threads, so perhaps those would be worth exploring if Thread.sleep() is limiting somehow. The Java Tutorial section on Concurrency is a good place to start.