A Comment on the Appearance of Total and Live Plots

When including managed memory and instances graphs in the graph view, e.g. Total instances or Total bytes, the graphs will often have a saw-tooth shape. Every time an instance is allocated, the plot value increases, and every time a garbage collect is performed, the total bytes and total instances are reduced. Ideally, after a garbage collect, the total number of instances on the heap should be equal to the number of live instances, but since the garbage collector does not look at all instances for lower generation GCs (generation #0 and generation #1), there might be instances that are not collected, even though they are not reachable.

The garbage collector is optimized using the assumption that young instances are very short-lived, and, thus, in order for the garbage collector to function optimally, very few instances should survive a generation #0 collect.

Below is a graph showing an ideal shape of the total bytes plot together with the live bytes plot. As you can see, at each generation #0 collect, the number of total bytes approaches the number of live bytes, and the live bytes are almost constant.

 

The next graph shows the plots when the conditions are not optimal. After each generation #0 collection, the total bytes have increased considerably, even though the live bytes are almost constant. Not even a generation #1 collection manages to decrease the total bytes on the heap. Only after a full generation #2 collection, does the number of total bytes become equal to the number of live bytes.

The main difference between the two scenarios presented above is that, in the first scenario, the instances are very short-lived, and in the second scenario, the instances survive for much longer. Also note that the number of live bytes is almost constant at around 10,000 Kbytes in both cases, but, in the first case, the memory overhead is only about 200 Kbytes, while in the second case, it is almost 20,000 Kbytes. Obviously, the second scenario should be avoided if possible, since it has a much higher memory overhead and performs more generation #2 collections, which is an expensive thing to do.

.NET Memory Profiler User Manual

© Copyright 2002-2019. SciTech Software AB.

For information about .NET Memory Profiler, see the product site at http://memprofiler.com

.NET Memory Profiler is developed by SciTech Software AB