Tracking Memory Consumption Metrics With JMH What&How

[Kirk Pepperdine]

Hi Jens,

Interesting….. I find a much less intrusive way of looking at memory is to simply use the data in the GC logs. Yes, they also suffer from inaccuracies but over a long enough benchmark the errors settle out in the dust. We also look at about a half a dozen additional metrics but you can’t get to them directly from SA counters. The one metric that is missing and can have an impact on GC performance is the rate of mutations. You should be able to get a handle on this value by looking at the refinement queue in G1 or card table updates with the generational collectors. This also will not be accurate but it is a measure. Unfortunately you will have to instrument the JVM to get these values but for benching it’s an acceptable option. Another cheap way to estimate allocation is to count the number of collections and multiply that by the size of Eden. Yes, it doesn’t take into consideration of waste or allocations directly in tenured but the waste should be 2% or less and in a bench you should be able to control or at least understand the number of allocations in tenured. You can contact me offline is you’d like a copy of our GC log analysis tooling.

Kind regards,
Kirk

> quite a (long) while ago I promised to do some work on tracking memory 
> consumption metrics and add profiler code to JMH.
> 
> To see and discuss what makes sense it needs some relevant benchmark
> scenarios, experimentations and some graphs. Took me a while. Everything that 
> I found out so far is compiled into a blog post:
> 
> https://cruftex.net/2017/03/28/The-6-Memory-Metrics-You-Should-Track-in-Your-Java-Benchmarks.html?pk_campaign=jmh
> 
> Feedback is highly appreciated!
> 
> Depending on the feedback I will start and compile some patches to get this 
> integrated into JMH.
> 
> Cheers,
> 
> Jens
> 
> -- 
> "Everything superfluous is wrong!"
> 
>   // Jens Wilke - headissue GmbH - Germany
> \//  https://headissue.com