172.829 – Time when the GC event started, relative to the JVM startup time. Measured in seconds.

[DefNew: 629120K->629120K(629120K), 0.0000372 secs – Similar to the previous example, a minor garbage collection in the Young Generation happened during this event due to Allocation Failure. For this collection the same DefNew collector was run as before and it decreased the usage of the Young Generation from 629120K to 0. Notice that JVM reports this incorrectly due to buggy behavior and instead reports the Young Generation as being completely full. This collection took 0.0000372 seconds.

Tenured – Name of the garbage collector used to clean the Old space. The name Tenured indicates a single-threaded stop-the-world mark-sweep-compact garbage collector being used.

1203359K->755802K – Usage of Old generation before and after the event.

(1398144K) – Total capacity of the Old generation.

0.1855567 secs – Time it took to clean the Old Generation.

1832479K->755802K – Usage of the whole heap before and after the collection of the Young and Old Generations.

(2027264K) – Total heap available for the JVM.

[Metaspace: 6741K->6741K(1056768K)] – Similar information about Metaspace collection. As seen, no garbage was collected in Metaspace during the event.

user – Total CPU time that was consumed by Garbage Collector threads during this collection

sys – Time spent in OS calls or waiting for system event

real – Clock time for which your application was stopped. As Serial Garbage Collector always uses just a single thread, real time is thus equal to the sum of user and system times.

The difference with Minor GC is evident – in addition to the Young Generation, during this GC event the Old Generation and Metaspace were also cleaned. The layout of the memory before and after the event would look like the situation in the following picture: