JVM options to get full visibility on generation behavior and GC loganalysis tools.
Jon.Masamitsu at Sun.COM
Mon Jun 23 14:00:39 UTC 2008
You can find source for a tool called GChisto at
It's open source. It parses PrintGCDetails output
but if you turn on flags which cause printing to be
interspersed with the PrintGCDetails output, it may
or may not work.
Regarding PrintHeapAtGC output at the end of a CMS
collection, it's not there probably as a matter of the
format of the output. The PrintHeapAtGC includes the
"top" of a generation where "top" is the next
space in a generation to be allocated. CMS is a non
moving collector (i.e., it maintains its free space
in free lists) so there is in general no "top".
Rainer Jung wrote:
> Alex Aisinzon schrieb:
>> I have several questions:
>> * I add the following parameters to get good GC logs:
>> “-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
>> -XX:+PrintGCApplicationStoppedTime". I wonder if some additional
>> options are useful. By example, the timestamps only track time
>> since the JVM was started. To correlate an incident with
>> application time stamps, it would be much more useful to have
>> those time stamps use regular dates (2008-06-17 11:58:11,23 by
> Also useful: -XX:+PrintTenuringDistribution
> Timestamps: yes unfortunately until lately there were no absolute
> timestamps available, only relative to JVM start. In 1.6.0_04 the new
> flag -XX:+PrintGCDateStamps has been implemented. See
> http://java.sun.com/javase/6/webnotes/ReleaseNotes.html (look for the
> bug id).
>> * I have not found a good tool to analyze these logs and have to do
>> that analysis by hand. HPJTune (HP) and GCViewer (TagTraum) are
>> sometimes good enough but does not work when using more refined GC
>> options like Parallel New Garbage Collection.. PrintGCStats is a
>> last one that I have not found very useful either. Are there other
>> tools available that someone could recommend?
> The same question form here: if someone did the work of writing a parser
> for those human readable but not really machine usable logs which would
> work with various flag combinations of verbosity, GC algorithms and JVM
> versions that would be really great.
> By the way: some things are unfortunately logically missing in the log
> files, like HeapAtGC at the end of a CMS. You can only get the status
> for the memory regions when the next minor GC runs, but not at the end
> of a CMS :(
>> In comparison, the IBM JDK provides a single GC output format by using
>> the verbose:gc option. IBM provides some very good tools to analyze
>> those logs.
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev