Profiling Results - Memory Usage

Home > Profiling Results

Profiling Results - Memory Usage

When you analyse memory usage, the Profiling Results tab displays data on object allocation and liveness. These results are displayed when you choose the following profiling tasks:

When you analyze memory usage, the profiling results displayed depend on which of the following options you choose:

  • Record both object creation and garbage collection (Object Liveness)

    This option provides information about how many objects of each type are still alive, as well as data on live objects.

  • Record object creation (Object Allocation)

    This option gives you information about the number, type, and location of objects that have been allocated. This profiling mode is a functional subset of object liveness profiling. The reason for having both modes is that pure object allocation profiling has a smaller performance and memory overhead.

To open the Profiling Results tab, click the Live Results button ( Live Results ) in the Profiler window.

Object Liveness Results

When you profile object liveness, the following information is displayed in the Profiling Results tab. (Click here for an example of the Profiling Results for Object Liveness.)

  • Live bytes (graph)
  • Live bytes (number)
  • Live Objects

    This is the size and number of tracked live objects for the given class at this moment. Tracked objects are a subset of all the allocated objects for which stack traces are collected, size is determined, and the liveness status is monitored. See the details of this statistical data collection method. As in Object Allocation profiling, it is advised that only a small proportion of objects, say 1 out of 10 or 1 out of 20, is tracked in order to keep both temporal and spatial overhead under control. The proportion of objects that are tracked can be changed in Analyze Memory Usage command dialog, or if you perform Custom Memory Profiling.

  • Tracked allocated objects

    This is the total number of tracked objects that have been allocated.

  • Average object 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 (GCs) that this object has survived. If generational garbage collector (which is default for the HotSpot JVM) is used, Profiler currently does not distinguish between partial (young generation) and full garbage collections. Average age is the sum of ages for all objects divided by the number of objects.

  • Number of survived generations

    This metrics for objects of a particular class is calculated in a complex way. In essence, it represents the total number of different object ages for objects of this class. If this number keeps growing steadily for a class, it is usually the sign of a memory leak. This is because a memory leak, or at least the most dangerous kind of memory leak, is a situation when objects for some class are allocated all the time, but at best collected only partially. By obtaining a reverse call graph for a leaking class you can determine which allocation site has the largest number of surviving generations — that is, which one generates most or all of the leaking objects. Knowing where an object has been allocated can, in turn, often help to identify the reason for a memory leak.

  • Total number of allocated objects

    The total number of allocated objects for this class. This number is the same number you get when you perform object allocation profiling, and represents the actual total number of objects of the given class that have ever been allocated.

You can sort classes by any of the above numbers by clicking on the respective column header or using the local popup menu. You can also choose to stop profiling certain classes.

To stop profiling for certain classes

When profiling object liveness, you can limit the classes you are profiling. You can right-click on a class to open the contextual menu which gives you the option to either stop profiling the selected class or all classes listed below the selected class. This option is useful when you are profiling an application with a large number of classes and you have already figured out which classes you are interested in (for example, the longest living or the leaking ones). In this situation, it often makes sense to avoid unnecessary runtime overhead (which may be quite high) by stopping profiling for all other classes.

How Profiler tracks object liveness

Profiler keeps track of the liveness status of only those objects whose allocation it previously registered. That is, it does not make heap snapshots like some other tools. Instead, it internally associates Java WeakReferences with objects that it registered allocated. If you started object liveness profiling in the middle of program execution, or if you invoke the Profile > Reset Collected Results Reset Collected Results while profiling is active, it is likely that you will not see all of the live objects that are on the heap of your target VM. However, when solving the most important problems that object liveness profiling addresses - allocating too many objects over time, and memory leaks - this is not a serious issue. In these situations it is more important to see how many objects the application allocates and garbage collects currently, rather than how many have been allocated long ago, perhaps even at application startup time.

Object Allocation Results

When you profile object allocation, the Profiling Results tab displays a list of classes (including array classes), with the total size and number of instances that have been allocated since you issued the instrumentation command. (Click here for an example of the Profiling Results for object allocation.)

Once you enable Object Allocation profiling, all classes currently loaded by the target JVM (and each new class as it is loaded) are instrumented to produce information about object allocations. The number of object allocations that Profiler presents is exact, whereas both the total object size and the reverse call graphs are by default obtained statistically. For more information about how Profiler does this, see Semi-statistical data collection in Memory Profiling.

Using the Results: A Leaking Application

Below, we show a demonstration of a leaking application in which we initially identify the instances of the class String that are leaking. That is because for despite the relatively small number of the objects themselves, the number of surviving generations for this class is much larger than for the other types, and this number is growing constantly:

Memory Leak Graphic

Then we identify the location in the code where the leaking String instances, as opposed to "healthy"String instances, are allocated. (For this location the number of surviving generations is, again, much higher than for others.)

Memory Leak Stack

See also


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 62 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm