The -Xverbosegc option prints
out detailed information about the Java heap before and after garbage
collection. The syntax is:
-Xverbosegc [:help] | [0 | 1] [:file
= [stdout | stderr | <filename>]]
The “:help” option
prints a description of the verbosegc output format.
The “0 | 1” option
controls the printing of help information. Specifying value “0”
causes the heap information to be printed after every Old Generation
GC or Full GC. Specifying value “1” (the default) causes
the heap information to be printed after every GC.
The “file = [stdout | stderr |
<filename>]” option
specifies the output file. The default is stderr, which directs the output to the standard error stream. Alternative
choices for the output file are stdout and a
user-specified filename.
-Xverbosegc sends log information
to stderr by default. It is preferable to send
the output to a specific logfile instead because runtime errors may
also send output to stderr. The following command
line sends -Xverbosegc output to a text file named yourApp_pid<pid>.vgc:
java -Xverbosegc:file=yourApp_pid<pid>.vgc yourApp |
At every garbage collection 20 fields are printed
as follows:
GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 %20 |
The following table contains brief descriptions of these 20 fields:
Table 1-15 Garbage Collection Field Information
| Field | Information
in Field |
|---|
| 1 | Type of GC:1: Scavenge (GC of New Generation only) 2: Old Generation GC or a Full GC 3: Complete background CMS GC 4: Incomplete background CMS GC
|
| 2 | Additional information based on GC type
in field 1. |
| 3 | Program time at the beginning of the GC,
in seconds. |
| 4 | GC invocation. Counts of background CMS
GCs and other GCs are maintained separately. |
| 5 | Size of the object allocation request
that forced the GC, in bytes. |
| 6 | Tenuring threshold—determines how
long the newborn object remains in the New Generation. |
| 7 | Eden Sub-space (within the New Generation)
occupied before GC. |
| 8 | Eden Sub-space (within the New Generation)
occupied after GC. |
| 9 | Eden Sub-space (within the New Generation)
current capacity. |
| 10 | Survivor Sub-space (within the New Generation)
occupied before GC. |
| 11 | Survivor Sub-space (within the New Generation)
occupied after GC. |
| 12 | Survivor Sub-space (within the New Generation)
current capacity. |
| 13 | Old Generation occupied before GC. |
| 14 | Old Generation occupied after GC. |
| 15 | Old Generation current capacity. |
| 16 | Permanent Generation (storage of Reflective
Objects) occupied before GC. |
| 17 | Permanent Generation (storage of Reflective
Objects) occupied after GC. |
| 18 | Permanent Generation (storage of Reflective
Objects) current capacity. |
| 19 | The total stop-the-world duration, in
seconds. |
| 20 | The total time used in collection, in
seconds. |
For more details about these fields, use the :help option or refer to the Java Programmers
Guide at:
http://docs.hp.com/en/JAVAPROGUIDE/index.html
To better understand how garbage collection works
in the Java VM, see the following webpage:
http://java.sun.com/javase/technologies/hotspot/gc/index.jsp
Additionally, HP recommends using the HPjmeter tool, which can graphically
display the -Xverbosegc data.
For more information about obtaining -Xverbosegc data for Java applications started without the -Xverbosegc option, see “Allocation Site Statistics and Zero Preparation Xverbosegc”.
Printable version
