 |
» |
|
|
|
The -Xverbosegc option,
available for the HP-UX HotSpot™ VM, was specifically designed to produce
ASCII garbage collection data files for in-depth analysis using HPjmeter. -Xloggc can
be useful for quick comparison of garbage collection behavior across different
platforms. Data Collection with -Xverbosegc | |
-Xverbosegc produces detailed information about the
performance of individual garbage collector types for the entire Java application.
To run your application with an option to capture the garbage collection
information, use the following command: java ... -Xverbosegc[:help]|[0|1][:file=[stdout|stderr|filename]] |
The following table lists examples of supported -Xverbosegc options
for capturing garbage collection data. This table provides information for
Java 1.5.0.04. Other versions may differ from this. HPjmeter correctly presents
and labels collected data based on the Java version running with the application.
To see the complete list of available options for the Java version you are
running, use java ... -Xverbosegc:help To see the availability of HPjmeter metrics from -Xverbosegc data
collection, see –Xverbosegc and –Xloggc Options and Their Corresponding
Metrics. Table 6-1 Supported -Xverbosegc options for Java 1.5.0.04 | 0|1 | 0 prints after every old generation garbage
collection or after a full GC 1 prints after every garbage
collection (default) | | :file=[stdout|stderr|filename] | stderr (default) directs output to standard error
stream stdout directs output to standard output stream
filename where the output shall be written |
At every selected garbage collection, the following
20 fields are printed. These values hold true for Java 1.5.0.04. Other versions
may differ. To see the complete list of available fields for the Java version
you are running, use java ... -Xverbosegc:help Table 6-2 Fields Captured in GC Log Data When Using -Xverbosegc print
options | %1 | Type of garbage collection. 1 = scavenge (of
new generation only) 2 = old generation GC
or full GC 3 = complete background, concurrent
mark and sweep (CMS) GC 4 = incomplete background,
concurrent mark and sweep GC 11 =
Ongoing CMS GC | | %2 | This value varies depending on the value of %1.When %1 is equal to 1, %2 indicates
whether or not a parallel scavenge occurred. Possible values are: n(>0): parallel scavenge with n number
of parallel GC threads
When %1 is equal to 2, %2 indicates
that an old generation GC or full GC has occurred. Reasons for the GC are
given as: 1: Allocation failure, followed by a failed
scavenge, leading to a full GC 2: Call to System.gc made 3: Tenured generation is full 4: Permanent generation is full 5: Scavenge followed by a train collection 6: Concurrent-Mark-Sweep (CMS) generation
is full 7: Old generation expanded on last scavenge 8: Old generation too full to scavenge 10: Allocation profiler triggered 11: JVMTI-forced garbage collection 13: Last ditch collection 14: GC Locker-Initiated GC 15: Heap Dump Triggered GC (HP implementation) 16: Heap Dump Triggered GC
When %1 is equal to 3, %2 indicates
that a complete background, concurrent mark and sweep GC has occurred. Reasons
for the GC are given as: 1: Occupancy > initiating occupancy 3: Incremental collection will fail 4: Linear allocation will fail
When %1 is equal to 4, %2 indicates
that an incomplete background, concurrent mark and sweep GC has occurred as
a result of exiting after yielding to foreground GC. The form for this data
set is given as n.m where n is
the GC reason as follows: 1: Occupancy > initiating occupancy 3: Incremental collection will fail 4: Linear allocation will fail 6: Incremental CMS garbage collection
and m indicates the background CMS state
when yielding, as follows: 7. Abortable pre-cleaning
When %1 is
equal to 11, %2 indicates
the stop-the-world phase of CMS GC, as follows: 2: Initial marking (first stop-the-world
phase) 4: Final marking (second stop–the-world
phase)
| | %3 | Program time at the beginning of the collection, in seconds | | %4 | Garbage collection invocation. Counts of background CMS garbage collections
and other garbage collections are maintained separately | | %5 | Size of the object allocation request that forced the GC, in bytes | | %6 | Tenuring threshold - memory allocation that determines how long newborn
objects remain in the new generation, in bytes. These spaces are reported:Occupied before garbage collection (Before) Occupied after garbage collection (After) Current capacity (Capacity)
| | %7, %8, %9 | Eden sub-space within the new generation, in bytes. These spaces are
reported: | | %10, %11,%12 | Survivor sub-space within the new generation, in bytes. These spaces
are reported: | | %13, %14, %15 | Old generation, in bytes. These spaces are reported: | | %16, %17, %18 | Permanent generation, in bytes. These spaces are reported for storage
of reflective objects: | | %19 | Total stop-the-world duration, in seconds. | | %20 | Total time used in collection, in seconds. |
Data Collection with -Xloggc | |
-Xloggc directs a smaller set of data to a file than
what is available with -Xverbosegc. For every garbage collection, the following six
fields are printed to the log file: Cumulative time since data collection began (in seconds) Heap in use before the GC event Heap in use after the GC event Current maximum heap size
To capture -Xloggc data, use the following command: java ... -Xloggc:filename |
To see the availability in HPjmeter of metrics
derived from -Xloggc data, see –Xverbosegc and –Xloggc Options and Their Corresponding
Metrics. Naming GC Data Files | |
The following table shows the file name formats used by default when
naming files containing garbage collection data. You may want to follow this
convention when naming GC data files, but it is not required. Table 6-3 Default File Name Suffixes for GC Data | Option | File Name Suffix |
|---|
| -Xverbosegc | .vgc | | -Xloggc | .vgc |
|
Printable version
