Compare jstat vs verbosegc vs visualvm vs HP J2EE Diagnostics !!

Below illustrates the comparison bet. verbose GC vs jstat (with gcutil option ) vs visualvm information vs jconsole information vs hp j2ee diagnostics

Before going further, the two GCs that are used in this example are ‘copy’ for young gen and ‘MarkSweepCompact’ for tenured/major gc

            VerboseGC:

            java -verbosegc

-XX:+PrintGCDetails

-XX:+PrintGCApplicationConcurrentTime

-XX:+PrintGCApplicationStoppedTime           

-XX:+PrintGCTimeStamps

Verbose GC log says tenured collections happened when ever the heap usage increased to 20Meg. Unfortunately the polling mechanism of visual vm and jconsole not able to capture the data points in that small interval. While jstat (polled at 1 sec interval) also says every sec there was/were FGC event/s happened and it also confirms that a total of 240 full gc events happened which coincides with the total number of Tenured collections indicated in the verbose gc log (jstat counts all tenured and full collections as FGC events)

The above fact is proven by uploading the raw data from jconsole to csv file. Which shows only 67 entries, that means it has not captured all 240 FGC events/major collections in verbose gc log. Infact it did not captured even 67 major collection points as those 67 data points are basically shows the heap usage points.. So in the jconsole graph below, all the major and Full GC events are not visible. Infact to be very strict, the graph is misrepresenting the major GC threshold (which is around 20 MB as per verbosegc logs & confirmed by jconsole VM Summary tab’s committed memory = 22MB, also in the heap usage graph legend). So, the graph most of the times representing the fullgc threshold as 14MB and showing in some instance(lucky) as around 20MB

Same applies to visualvm graph… we can not export visualvm graph’s raw data…

Click to see GC behaviour frm verbosegc log & exported JConsole Heap usage graph data

(in the above gc log, at timestamp 275.312: u see, its indicated as FULL GC (System) which means its a system trigged FGC.. Infact this was a manual forced GC done from visualvm. So FGC entry here indicates heap mem which is not occupied completely to the upper limit )

 JVisualVM:

 JConsole:

HP J2EE Diagnostics Probe:

Note: In the above comparison, the example program that was used has no memory leak. And the word FGC is actually refering to major GC or tenured GC. Infact, in the above test there was no Full GC happend though jstat convention is always FGC events even for major or real FGC.

And you can clearly identify when a real FGC happend by looking in to the verbose gc logs for the entry "Full GC".