Analyzing Memory Data 

Use

You can evaluate and display all the profiling data related to the memory used by the application.

Prerequisites

You have closed a profiling session in which you had activated the recording of memory data. You are now in the evaluation overview for this session.

More information: Evaluating Sessions.

Procedure

You can now evaluate the analyses you had activated for your profiling session. The memory analysis node contains the subnodes for which you collected profiling information (see Setting Analysis Parameters for Memory Usage).

The information contained in the subnodes is described below.

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 lines have a triangle at the front to indicate that the lines can be expanded by double-clicking on them, and then detailed information is displayed in the expanded lines. 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. The age limit can also be selected in the header line.  The default value is 4.

More information: How the Local Garbage Collector Works

This table contains the following information:

●      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)

If you select a new age limit in the header line, the analysis values are reorganized into the new age classes, and the contents in the Y and O columns refreshed.

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, etc.) 

Graphical Information

The graphical evaluation is only available if several GCs were run, or were started manually during the profiling. For one GC only the number of objects over a period of time across multiple GC runs cannot be displayed.

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. More information: How the Shared Garbage Collection Works.

The shared GC uses a distributed algorithm. A closed shared GC cycle runs through three phases:

...

       1.      Start: A VM triggers the shared GC, for example by a VM-specific complete GC. All cross-VM objects are selected, and a list is created of the VMs that have contributed to the GC.

       2.      Contribution: All VMs in this list make a contribution by deleting the selection of cross-VM objects that they still reference. Before this can be done, a complete local GC has to run in the VM.

       3.      Release: After all required VMs have made their contribution, the memory is released for the objects that are still selected.

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

●      Internal number of the shared 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. You can find out the meaning of the values from 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. The list contains the following information for each shared closure:

●      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.

More Information

Memory Management in the VM Container