Found this when studying Leyden performance.

JDK-8049304 added 1ms sleep on destruction path to catch up with threads updating the counters:
https://github.com/openjdk/jdk/blob/c00557f8f53ff729c8a1857a4ffcc585d3f8c6c4/src/hotspot/share/runtime/perfData.cpp#L268

This delay eats the execution time on very short runs. Look:

$ hyperfine -w 10 -r 100 ...

# Baseline
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello
  Time (mean ± σ): 19.9 ms ± 0.3 ms [User: 11.6 ms, System: 15.7 ms]
  Range (min … max): 19.4 ms … 20.7 ms 100 runs

# Disable UsePerfData altogether
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -XX:-UsePerfData -Xmx128m Hello
  Time (mean ± σ): 18.3 ms ± 0.3 ms [User: 11.4 ms, System: 15.7 ms]
  Range (min … max): 17.8 ms … 19.2 ms 100 runs

# Remove sleep(1ms)
Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello
  Time (mean ± σ): 18.8 ms ± 0.3 ms [User: 11.9 ms, System: 15.4 ms]
  Range (min … max): 18.4 ms … 19.6 ms 100 runs

The sleep in question looks opportunistic and not load-bearing for correctness (it cannot be, right?). If we still believe we need to coordinate the counter updates and deletions, we can use the GlobalCounter for syncs, see attached JDK-8348402-poc.patch. It performs reasonably well in the tests:

Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xmx128m Hello
  Time (mean ± σ): 18.9 ms ± 0.2 ms [User: 11.7 ms, System: 15.6 ms]
  Range (min … max): 18.4 ms … 19.3 ms 100 runs