FaqProfilerConceptGC

How do I read the data on garbage collection?

When profiling the memory usage of an application, you can view information on garbage collection in the Live Profiling Results window and the VM Telemetry window. These windows can provide you with data on the relative time spent in garbage collecting and the number of surviving generations.

These window display information on garbage collection in the application.
The VM Telemetry window displays high level information about object allocations and the Live Profiling Results window shows more detailed information.

Relative time. Relative time is measured as a percentage of the total execution time that the target JVM spends running garbage collection with all application threads suspended.

Surviving generations. This represents the number of different ages for all objects allocated on the JVM heap since the moment Profiler was attached to it.

Average age of object. The Live Profiling Results window shows 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, the IDE 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.

How to use this data

A steady growth in the age of an object usually indicates that some objects are leaking. 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.

This may be valuable information if you observe memory usage going up. In such situations, people usually start to suspect a memory leak. A memory leak, or at least the most dangerous kind of memory leak, is 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.

However, if you observe that the number of surviving generations remains stable, it is very likely that the root of the problem is not a memory leak, but some other problem.

One example is a growing number of concurrent threads, each of which allocates a large amount of memory for a very short time. In that case, you may observe gradual increase in the memory usage, which may ultimately cause an out of memory error. However, there is no leak, since each thread releases its allocated objects quickly, and memory recycling rate is in fact quite high.

Note: For technical reasons this monitor does not work when your target JVM uses the Concurrent Mark and Sweep garbage collector. This is the garbage collector that is activated using the -XX:+UseConcMarkSweepGC or -Xconcgc JVM command line option.