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

[Sergey Kuksenko]

Right now processing perf events we are skipping events from start 
(estimating delay), but we don't skip them from the end.
I think we should:
- (by default): skip before start time of the first iteration and skip 
after end time of the last iteration.
- (by options): select events only from the single iteration with some 
gaps from start and end (configurable). that allows us to do perfasm 
slice which are free from infrastructure effects.


On 04/16/2015 03:36 PM, Aleksey Shipilev wrote:
> 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
>

-- 
Best regards,
Sergey Kuksenko