Tracking Memory Consumption Metrics With JMH What&How
Kirk Pepperdine
kirk at kodewerk.com
Thu Apr 6 10:28:51 UTC 2017
> On Apr 6, 2017, at 12:23 PM, Jens Wilke <jw_list at headissue.com> wrote:
>
> Hi Kirk,
>
> thanks for the lively discussion.
It’s fun…
>
> On Donnerstag, 6. April 2017 14:31:15 ICT kirk at kodewerk.com wrote:
>> There is a lot going on here that remains hidden.
>
> True, there is a lot going on, it is hidden but hopefully not undetected.
>
> I have two working assumptions:
>
> 1)
>
> If any adoption (e.g. recompile, GC autotuning, OS+CPU cache warmup) happens,
> that would be noticeable indirectly in the measured performance.
Sometimes difficult to notice.
>
> 2)
>
> If the JVM has a consistent performance level for one minute, and the workload
> is identical, it will possibly not change after more time has passed.
This is the assumption that I would expect but I’ve found not to be true in all cases. I’d investigate to find an appropriate run time.
>
>> What I would suggest is that you get a handle on the JIT counts and run the
>> warmups until that value stabilizes for some period of time.
>
> As you said, there is a lot going on. Which means, it's hard to miss critical
> things. I think the statistical confidence is the better "general" truth to
> verify that there is no warmup or any other cause of deviations.
I’d use the internal JIT counters.
I don’t want to talk about GC, it’s an orthogonal yet important topic to consider.
>
> I consider minimizing the iteration runtime while meeting an accuracy goal as
> best practice, in case you like to run benchmarks continuously and get fast
> feedback.
That would be the dream.
Kind regards,
Kirk
More information about the jmh-dev
mailing list