Supported data types

The IBM® Monitoring and Diagnostic Tools - Garbage Collection and Memory Visualizer (GCMV) can process the following kinds of data in log files: verbose garbage collection, native memory, and trace garbage collection.

Verbose garbage collection data

Verbose logging is usually the first tool to use when diagnosing garbage collector problems. Verbose garbage collection (VGC) logs provide an insight into the operation of the garbage collector, and can provide information to help you make choices about policies and parameters.

In IBM SDK, Java™ Technology Edition

You can enable verbose garbage collection by using one of two command-line options: -verbose:gc, which sends output to the standard error (stderr) stream, or -Xverbosegclog:filename, which sends output to a specified log file.

An example of some verbose garbage collection data:

<verbosegc version="20051020_AA">
<af type="nursery" id="1" timestamp="Mon Nov 07 05:30:23 2005" intervalms="0.000">
  <minimum requested_bytes="56" />
  <time exclusiveaccessms="1.964" />
  <nursery freebytes="0" totalbytes="157286400" percent="0" />
  <tenured freebytes="523144240" totalbytes="524288000" percent="99" >
    <soa freebytes="496929840" totalbytes="498073600" percent="99" />
    <loa freebytes="26214400" totalbytes="26214400" percent="100" />
  </tenured>
  <gc type="scavenger" id="1" totalid="1" intervalms="0.000">
    <flipped objectcount="174743" bytes="18513664" />
    <tenured objectcount="0" bytes="0" />
    <refs_cleared soft="14" weak="389" phantom="0" />
    <finalization objectsqueued="3108" />
    <scavenger tiltratio="50" />
    <nursery freebytes="137812760" totalbytes="157286400" percent="87" tenureage="10" />
    <tenured freebytes="523144240" totalbytes="524288000" percent="99" >

In IBM SDK for Node.js

Use the --trace_gc command-line parameter to generate garbage collection data. You can additionally specify either the --trace_gc_nvp or --trace_gc-verbose parameters to generate more detailed, single-line or multiple-line information.

Example output:

[1240]      454 ms: Mark-sweep 5.0 (38.0) -> 1.7 (36.0) MB, 5 ms [allocation failure] [GC in old space requested].
[1240] Memory allocator,   used:  36865 KB, available: 1462271 KB
[1240] New space,          used:      0 KB, available:   1023 KB, committed:   2048 KB
[1240] Old pointers,       used:    886 KB, available:     11 KB, committed:   1519 KB
[1240] Old data space,     used:    381 KB, available:     10 KB, committed:   1199 KB
[1240] Code space,         used:    423 KB, available:    572 KB, committed:    996 KB
[1240] Map space,          used:     71 KB, available:     56 KB, committed:    128 KB
[1240] Cell space,         used:     15 KB, available:    112 KB, committed:    128 KB
[1240] Large object space, used:      0 KB, available: 1461230 KB, committed:      0 KB
[1240] All spaces,         used:   1777 KB, available:   1787 KB, committed:   6019 KB
[1240] Total time spent in GC  : 5 ms

Native memory

Use a memory usage profile (data for virtual memory usage over time) when diagnosing Java or Node.js out-of-memory conditions that are caused by the exhaustion of native memory. The method by which you obtain memory usage data depends on your operating system.

Trace garbage collection data in IBM SDK, Java Technology Edition

The trace garbage collector (TGC) provides more detailed information about some aspects of garbage collection. Use one or more TGC traces to obtain more detailed garbage collection information than that contained in a VGC log. Although several different types of TGC trace exist, for example compaction, dump, and scavenger, the only one that can be processed by the parsers in GCMV is the freelist trace.

Note: When you open a TGC log in GCMV, the Line plot display is blank, because by default, no TGC fields are enabled for plotting.

Use the -Xtgc:freelist parameter to obtain a trace. Before a garbage collection occurs, this trace generates information about the free list (a list of available storage areas) and object allocation statistics since the last garbage collection. For thread local heap (TLH) and non-TLH allocations, this information includes the total number of allocations, the average allocation size, and the total number of bytes discarded during allocation. For non-TLH allocations, the information also includes the average number of entries that were searched before a sufficiently large entry was found. Small TLH sizes and large numbers of searched entries can both indicate heap fragmentation.

An example section of TGC output generated by using the -Xtgc:freelist parameter:

 *8* free         0
 *8* deferred     0
total                0
<Alloc TLH: count 3588, size 3107, discard 31> 
< non-TLH: count 6219, search 0, size 183, discard 0>

In an example graph of TGC data, you might see that the number of entries on the free list is initially low, because most objects are still active and the heap has no fragmentation. As the application runs, heap fragmentation increases and the size of the entries on the free list therefore decreases. Because of this behavior, after the application has been running for a few collections, the number of entries on the free list is higher. If forced compactions occur periodically, the effect of the compaction is visible in the graph as a sudden increase in the size of the entries on the free list.

You can view the relationship between the number of entries on the free list and the size of the entries on the free list by plotting the size of the entries on the free list. In the previous example, the size of the entries drops after a few collections have occurred.