Checking the health of the heap using GC verbosity

In order to check the health of the heap, we can read the garbage collections logs.
 
this can be done by adding the following start-up options to the JVM:
-verbose:gc -Xlogger:gc.log -XX:+PrintGCDetails
 
there are two interesting issues to learn from this output regarding the GC process which I'll show in this post:
1) how much time the GC takes
2) how much bytes were tenured (moved from the young generation to the old generation after the GC)
 
Here's one log entry that describing a minor GC, and I'll explain its structure:
 
11.970: [GC 11.970: [DefNew: 93248K->4863K(104896K), 0.0289958 secs] 98507K->10122K(1036992K), 0.0290992 secs]
 

1. let's start with the DefNew (which is the young generation):

[DefNew: 93248K->4863K(104896K), 0.0289958 secs]
DefNew space - the entire young generation (Eden, From, To).
its capacity before the GC was 93248K.
its capacity after the GC is 4863K.
its total (maximal) capacity is 104896K.
the young generation shrank from 93248K to 4863Kb in 0.0289958 secs.
 

2. and now we'll go to the entire heap:

98507K->10122K(1036992K), 0.0290992 secs]
the entire used heap (young + old generations) changed from 98507K to 10122K, from a total available heap of 1036992K.
 
3. calculate the number of bytes that were tenured as a result of this GC
the entire heap size before the GC was 98507K, of which the young generation occupied 93248K.
this means the old generation occupied the remaining 5259K.
after the GC, the entire heap size was 10122K, of which the young generation occupied 4863K.
this leaves 5259K to the old generation.
 
therefore, no data was tenured as a result of this GC, because the capacity of the old generation before and after the GC remains the same.
this means that no bytes were moved from the young generation to the old generation.

 

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com