Perfasm attributes 39% of cycles to JMH infrastructure in my benchmark

[Aleksey Shipilev]

Hi Chris,

On 16.04.2015 15:10, Chris Vest wrote:
> I have this benchmark, built with JMH 1.8 (change the neo4j.version property to “2.2.1” when building):
> https://github.com/chrisvest/traversal-benchmark <https://github.com/chrisvest/traversal-benchmark>

> if (control.isLastIteration()) {
>     while(!PageCacheTraversal_jmh.tearTrialMutexUpdater.compareAndSet(l_pagecachetraversal0_G, 0, 1)) {
>         if (Thread.interrupted()) throw new InterruptedException();
>     }
> Apparently that “tearTrialMutexUpdater” is pretty popular. Does this influence my results, and if so, can I do anything to reduce the effect?

That code is a spin-lock that provides the mutual exclusion guarantees
for @TearDown at your @State(Benchmark). It is unlikely to cause issues
for your benchmark measurement, since sync iterations will make sure the
benchmark threads are only measuring the case when all threads are busy
with actual work.

So the issue you are seeing is that external profilers like perfasm
inevitably catch the infrastructure costs. In this case, it would seem
the @TearDown is slow enough that other N-1 threads are busy-waiting for
too long.

Implementation-wise, that is done to make benchmark threads always hot
during the iteration, otherwise we may just block and wait, consuming no
cycles. I wonder, however, if we can demote the CAS-ed busy wait into
more light-weight test:
  http://cr.openjdk.java.net/~shade/jmh/busy-wait-test-1.patch

Please try to build it with 1.9-SNAPSHOT, and try on your config. Does
it help your case?

-Aleksey