GCProfiler enhancement ideas

[Aleksey Shipilev]

Hi,

Sorry for the late reply.

On 04/18/2016 07:15 PM, Jens Wilke wrote:
> # maximumUsedAfterGc
> 
> The maximum used heap size after a GC run over all GC events. That's not particular interesting for
> microbenchmarks, but for benchmarking libraries I'd like to have some rough metrics about the absolute
> memory consumption. It gives useful information, here is a protoype:
> https://github.com/cache2k/cache2k-benchmark/blob/master/jmh-suite/src/main/java/org/cache2k/benchmark/jmh/GcProfiler.java

Okay, that makes sense. The question is to how to aggregate these
metrics, taking transient surges into the account. Especially the surges
during the young collections? Probably deserves to be split
per-generation too.

> # gc.churnSum (or gc.churn.total?)

gc.churn.total

> Currently the churn is added by space. I think the space names can be different depending on the configuration.
> What about adding the total as a result metric that has a constant name? This way we don't have to change the
> analysis after a GC configuration change.

Yes, makes sense.

> # gc.count.<type>
> 
> Here it's the other way around. Currently, there is only a total count of all GC events. What about adding separate 
> counts per GC type (if that is reported meaningful via the notification)? 

You will have to drop GarbageCollectorMXBean scalar values then, and
re-use the GC notifications directly for this. GCProfiler already does
this, so no problem.

> Thoughts? Should I prep a patch? (OCA is signed)

Yes, let's see what you got.

I think these improvements would force us to beef up GCProfiler with
options support to disable some metrics by default. These are the
metrics that should probably be available by default:
gc.churn.total.norm, gc.alloc.total.norm, gc.count.total -- and others
should be easy to enable. See other profilers, e.g. StackProfiler to see
how they treat Options.

Thanks,
-Aleksey