Analyzing Memory Data

Object allocations

If you choose the Object Allocations node, a list of the instantiated object classes is displayed. For each class the following is listed:

• The full name of the class, including the package name, and the suffix '[]' if it is an array class

• The number of object instances

• The total size of the instances in bytes, whereby the size of an instance does not include all possible referenced objects.

All table rows have a triangle at the front to indicate that the rows can be expanded by double-clicking on them, and then detailed information is displayed in the expanded rows. In this case these are the method locations of the allocations in the form of stack traces, which specify where the instances were allocated in the application.

Sort

By default the table is sorted in descending order by the total size of the object instances, which means that you can quickly identify classes with potential memory problems. Using the standard pushbuttons the table can be:

• Sorted by the other columns

• Searched by character strings

• Exported as text (without stack traces, or only with the currently expanded stack traces, or with all stack traces)

Class statistics

If you choose the Class Statistics node, a table of "live" objects (still referenced) following a local VM garbage collection run during the profiling session is displayed. In the header line you can select the number of the GC and the VM and display the class statistics for it.

The statistics distinguishes between young and old objects. Old objects are those that have survived a specific number of GCs. This does not yet apply to young objects. This age limit can be selected in the header. The default value is 4.

For more information, see How the Local Garbage Collector Works

This table contains the following information:

• The full name of the class, including the package name, and the suffix '[]' if it is an array class

• Number of object instances

• Total net size of the instances in bytes, whereby the size of the instance does not include all possible referenced objects.

• Total gross size of the instances in bytes, whereby the size of the instance does include all possible referenced objects.

The last three values are listed in separate columns for:

• Young objects (columns start with "Y" for young)

• Old objects (columns start with "O" for old)

• All objects together (columns start with "T" for total)

Sort

By default the table is sorted in descending order by the gross number of old objects, which means that you can quickly identify possible candidates for memory leaks. You can perform the standard functions on the table (sort, total, print, and so on).

Graphical Information

If you double-click on a table line, a line graph is displayed representing the age development of objects from this class with the heading "Statistics of Live Objects for Class: <class name>". The X-axis represents the time in the form of consecutive GC runs. The number of objects after each GC has ended is shown on the Y axis. Three graphs represent the objects from young, middle-aged, and old generations. The generation ranges are derived from the defined age limits and are shown in the color legend beneath the chart.

Identification of Possible Memory Leaks

Normally the number of young and old objects should stay more or less constant over time. An increasing number of old objects indicates a memory leak, since objects have evidently not been caught by the GCs.

Reference chains

If you choose the Reference Chains node, a list of reference chains for all accessible (that is, still referenced) objects following one of the local VM garbage collections run during the profiling session. In the header line you can select the number of the GC and the VM whose reference chains you want to view.

The list contains the following information:

• Full class name and class loader name in the format <classname>@<loadername> #id, whereby id is a unique internal ID for the class loader

• Number of object instances in this class

All lines have a triangle at the front to indicate that the lines can be expanded by double-clicking on them. Detailed information is displayed in the expanded lines. In this case this is the entire reference chains for the individual instances. To keep the display clear, the chains are divided into subgroups. If you continually expand the lines you will finally see the detailed reference chains.

The following information is displayed:

• "stored in field 'xyz' of"

• "stored in static field 'xyz' of"

• "stored at index nn in array"

• "the class of object"

• "is the superclass of"

• "is the root of the shared closure, which contains"

• "stored in global root"

This provides you with information about the objects and classes for which references are kept for the instance in question. The last element in the chain is the object that the instance is keeping alive through this chain. Note that one single instance can be kept alive across several chains at the same time. In such cases the table always contains only one of the chains.

Sort

By default the table is sorted in descending order by the number of object instances of a class, which means that you can quickly identify class candidates for memory leaks. When you track reference chains, you would ultimately come across critical objects that the instances are keeping alive.

Local VM Garbage Collection:

If you select the GC Statistics node, the statistics for all local VM garbage collections run during the profiling session are displayed (see How the Local Garbage Collection Works). If you have not reserved a VM for the profiling, the statistics include the GCs in all the VMs of the VM Container.

In the upper section of the display the header data of the GCs is displayed in a table. The table lists the GCs and contains the following information:

• Internal number of the VM in which the GC was run

• Internal number of the GC

• Type of GC (full, partial, shared (contributes to a shared GC)

• The reason for the GC (for example, allocation failed (memory request failed), or it was requested by a shared GC)

• Size of the requested memory in bytes if the reason for the GC was a failed memory request.

• Time taken in microseconds between start and end of GC

• CPU time in microseconds taken by the GC

• Number of page faults occurring during the GC. A large value indicates that the setting for the heap memory area in the Java VM might be too large.

• Time and date when the GC began

If you double-click on a line in the table, the full statistical data of the GC is mapped in the lower section of the display. The meaning of the values is described in the F1 help texts for the label texts and output fields. The values are grouped together as follows:

• Header Data: These are the same values as in the table lines.

• Young Generation: All objects are initially allocated to this memory area. Only when a specific number of GCs (specified in the system profile parameter xyz) have survived, are they promoted to the old generation memory area. The values in this group indicate the proportion of short-living objects in the memory.

• Old Generation: All objects that have survived a specified number of GCs end up in this memory area. The values in this group indicate the proportion of long-living objects in the memory.

• Classes: The values in this group indicate the proportion of class objects in the memory.

• java.lang.Reference Objects: You can find the meaning of these object types from the F1 help texts for each of the subclasses:

  • SoftReference

  • WeakReference

  • PhantomReference

  • FinalReference

Sort

By default the table is sorted by VM number, and within a VM by GC number, which means the GCs are usually display in chronological order.

Shared Garbage Collection:

If you choose the node Shared GC Statistics, the statistics for all shared VM garbage collections run during the profiling session are displayed.

To interpret the statistics, you need to know about the algorithm of the shared GC. For more information, see How the Shared Garbage Collection Works.

The shared GC uses a distributed algorithm. A completed shared GC cycle has three phases:

1. Start: A VM triggers the shared GC, for instance, through a full local VM GC. All shared VM objects are flagged and a list of VMs that have contributed to the GC is created.

2. Contribution: All VMs in this list contribute by deleting the flags for the shared VM objects that they still reference. This first requires a full local GC within the VM.

3. Release: Once all required VMs have made a contribution, the memory of objects still flagged is released.

In the upper section of the display the header data of the GCs is displayed in a table. The table lists the GCs and contains the following information:

• Internal number of the GC

• Reason for the shared GC (for instance, shared allocation failed or shared watermark exceeded)

• Size of the memory gained in bytes (the memory released for the shared GC)

• Time in microseconds between the start and the end of the release phase of the shared GC.

• Time and date when the GC began

If you double-click on a line in the table, the full statistical data of the shared GC is mapped in the lower section of the display. The meaning of the values is described in the F1 help texts for the label texts and output fields. The values are grouped together as follows:

• Header Data: The meaning of these values in the same as in the table lines.

• "Release Phase": The values in this group provide information about the core activity of the shared GC.

• "Released Shared Items": This specifies how many objects of the five types of shared VM memory objects (shared class loaders, shared classes, shared closure versions, shared interned strings, and shared locks) were released in this shared GC.

• "Shared Classes": The total size in bytes of all classes before and after this shared GC provides information about the proportion of class objects in the shared VM memory.

• "Shared Data": The total size in bytes before and after this shared GC provides information about the proportion of all the other object types in the shared VM memory.

• "Shared Memory Pool": The percentages indicate the watermark of the shared VM memory before and after the shared GC.

Sort

By default the table is sorted by GC number, which means the shared GCs are usually displayed in chronological order.

Shared closure operations

If you choose the node Shared Closure Operations, a list of the shared closures that were accessed during the profiling session is displayed.

• Full name, including the closure domain Name. Separators in closure domain path is the backslash ('/').

• Internal ID that uniquely identifies the shared closure in the VMC

• Version number

• Frequency and size in bytes, in which the operations below were performed on the individual versions of the shared closures:

  • Created

  • Copied

  • Mapped

  • Deleted

Versioning

If a table line had a triangle symbol at the front, multiple versions of the shared closures have been used, and the table line contains the total values from all versions. You can expand these lines by double-clicking on them. The individual values of the versions are then displayed in the expanded lines.

For shared closures with only one version the version number is attached to the closure name in the format #<version number>.

Sort

The table is sorted alphabetically in ascending order by the full name of the shared closure.