Meaning of the hs_gc profiler counters in JMH

Question

I'm using the JMH benchmarking tool with the hs_gc hotspot profiler.

The issue I'm having is that I am unsure what the output counter values mean and cannot find a reference on the net.

Would anyone be able to point me in the direction of a specification or explain these values?

I have pasted an example output below:

HS(GC) | difference: {

sun.gc.collector.0.invocations=16,
sun.gc.collector.0.lastEntryTime=37106821,
sun.gc.collector.0.lastExitTime=37109336,
sun.gc.collector.0.time=1528884,

sun.gc.collector.1.invocations=6,
sun.gc.collector.1.lastEntryTime=34419368,
sun.gc.collector.1.lastExitTime=35532892,
sun.gc.collector.1.time=6721387,

sun.gc.generation.0.space.0.used=872712984,
sun.gc.generation.1.space.0.used=5721334504,
sun.gc.generation.2.space.0.used=4848,

sun.gc.policy.avgBaseFootprint=5312,

sun.gc.policy.avgMajorIntervalTime=-667,
sun.gc.policy.avgMajorPauseTime=-41,

sun.gc.policy.avgMinorIntervalTime=-557,
sun.gc.policy.avgMinorPauseTime=1,

sun.gc.policy.avgOldLive=88064,
sun.gc.policy.avgPromotedAvg=421184,
sun.gc.policy.avgPromotedDev=364832,
sun.gc.policy.avgPromotedPaddedAvg=1515648,
sun.gc.policy.avgSurvivedAvg=1056640,
sun.gc.policy.avgSurvivedDev=-189440,
sun.gc.policy.avgSurvivedPaddedAvg=488320,
sun.gc.policy.avgYoungLive=2708352,

sun.gc.policy.liveAtLastFullGc=5721334504,
sun.gc.policy.liveSpace=2801664,

sun.gc.policy.majorGcCost=5,
sun.gc.policy.majorPauseYoungSlope=-3,

sun.gc.policy.minorGcCost=2,
sun.gc.policy.minorPauseTime=3,
sun.gc.policy.minorPauseYoungSlope=1,

sun.gc.policy.mutatorCost=-7,

sun.gc.policy.oldEdenSize=11534336,
sun.gc.policy.promoted=4584928,
sun.gc.policy.survived=6194624,

sun.gc.tlab.alloc=12852845,
sun.gc.tlab.fills=-15,

sun.gc.tlab.gcWaste=-100979,
sun.gc.tlab.maxFills=-22,
sun.gc.tlab.maxGcWaste=-100859,
sun.gc.tlab.maxSlowAlloc=-5,
sun.gc.tlab.maxSlowWaste=8826,

sun.gc.tlab.slowAlloc=-5,
sun.gc.tlab.slowWaste=8849}

Answer 1

The Serviceability in HotSpot: HotSpot Jvmstat Performance Counters has the following warning about this:

The counters have structured names such as sun.gc.generation.1.name, java.threads.live, java.cls.loadedClasses. The names of these counters and the data structures used to represent them are considered private, uncommitted interfaces to the HotSpot JVM. Users should not become dependent on any counter names, particularly those that start with prefixes other than "java.".

Additional warning: all source code links below point to the specific hg.openjdk.java.net/jdk7u/jdk7u60 branch and the specific file revisions. The links themselves should work forever, but as the JVM evolves the new file versions can make information in this post obsolete.

The first source of information is the jstat documentation (jstat 8 unix docs, jstat 8 windows docs, jstat 7 docs). It provides a human-readable albeit short description for a lot of performance counters, for example:

FGC: Number of full GC events.

The second source of information is the jstat source code (jstat source code, jdk7u60 branch) and specifically its resource files: jstat_options and jstat_unsupported_options. For example, searching for FGC in jstat_options results in the following snippet:

column {
  header "^FGC^"    /* Full Collections */
  data sun.gc.collector.1.invocations
  align center
  width 5
  scale raw
  format "0"
}

Using jstat_options source code and jstat documentation it is possible to map most of internal counter names with prefixes sun.gc.collector and sun.gc.generation to human-readable descriptions or at least get some additional information from the comments inside jstat_options file.

Most of the counters with sun.gc.policy prefix are defined in gcPolicyCounters.cpp and gcAdaptivePolicyCounters.cpp and also in the GC-specific implementations (look for somethingCounters.cpp files in GC-specific folders located on the same level as shared folder) but i was not able to find human-readable descriptions for them.

I was not able to find where counters with sun.gc.tlab prefix are defined. Checking-out the full JDK source code and grepping it for relevant counter names should do the trick for those inclined to find everything.