Object Allocation Analysis view

Object allocation analysis enables you to capture the information pertaining to the type, number, and age of objects that have been allocated. If you select the object allocation tracking, all classes loaded by the target JVM are instrumented to produce information about object allocations.

About this task

The object allocation analysis records both the object creation and garbage collection information to provide information about how many objects of each type are still alive, as well as data on live objects. The object allocation analysis enables you to force a Garbage collection Garbage collection icon on the target application to identify the surviving objects and identify the memory leaks in your application.

To perform a Object Allocation analysis (Heap/Memory) profile of an application, you must complete the following steps:

Procedure

  1. Follow the steps to launch or attach to a process for profiling.
  2. Under the Profile Settings tab, set any desired filters by clicking on the Edit options.
  3. Select Memory Analysis, click Edit Options and select Track object allocation sites.
  4. The object allocation analysis provides a comprehensive view of the application object analysis with the following information:
    Option Description
    Live instances and Active size This is the size and number of active live objects for the given class.
    Total instances and total size This is the total number of object instances and their sizes including the live objects.
    Average age This is the average age for the tracked live objects of this class. The age of the object is measured as the number of garbage collections that this object has survived. Average age is the sum of ages for all objects divided by the number of objects.
    Allocation details The allocation details provides the information about where the object was allocated, the class, method and line number that made the object allocation.

What to do next

Garbage Collection

You can force a garbage collection on the application by a click on Garbage collection icon in the profiling navigator. The garbage collection updates the surviving objects in the heap following the garbage collection and the ages for all objects allocated on the JVM heap since the moment Profiler was attached to it.

Identifying application memory leak

The Object allocation analysis view provides the number of surviving generations for a class. If this number is much larger than the rest of the application and is constantly growing then this object is a candidate for memory leak analysis. In the profiling navigator, select the monitor and click on "Run garbage collection" to force a garbage collection event, monitor the age of the object. If the object age continues to grow, then this object is being held and not garbage collected. Navigate to the allocation details view to determine the object allocation site of the leaking object. On the other hand, if this metrics stabilizes and does not grow noticeably thereafter, it's guaranteed that your application does not have any growing memory leaks.

In what situations will memory objects appear in the Object Allocations view

If it seems like expected data is not appearing in the object allocations view, it may be useful to consider under what conditions data will appear here.

The primary reason for data not appearing is due to the data being filtered out by filters that are set before the profiling session has begun, or while the profiling session is active.

For an object to appear in the object allocations profiling view, complete the following steps:

  1. The class/method that creates the object must not be filtered out by the pre-launch filter set. This would be the class that contains the 'new' keyword (or uses reflection to instantiate).
    • The profiler will not instrument classes that have been filtered out. A class must be instrumented in order for it's 'child objects' to be tracked.
  2. The object itself being created must not be filtered out by the pre-launch filter set.
    • The object that is being created must not be filtered out: it must not be EXCLUDED in the pre-launch filter set. All objects that you wish to appear in the view must NOT be filtered out.
  3. The object is not being filtered out by the Object Allocations view's UI filter.
    • This is the filter that is set from right within the Object Allocations view. A few of the preprogrammed defaults are 'No Filter' and 'Default Filter'. If you have the 'No Filter' option selected here, you do not need to worry about this.

And it is import to distinguish between the two filter types:

  • Pre-launch filters: This is the filter that is specified before the application has begun profiling. It is a dialog box that has multiple filter sets preprogrammed, and allows you to add additional rules for package/class/method to INCLUDE/EXCLUDE)
  • Object Allocations View UI filter: This is the filter that is set from right within the Memory Allocations view. A few of the pre-programmed defaults are No Filter and Default Filter.

Pre-launch filters are set before launch, and before the profiler has started to profile (and should exclude all classes that are unrelated to the application under test). In contrast, the object allocation view UI filter is set once profiling has started, and in the case of Memory Analysis, should always be set to No Filter.

Feedback