Hunting Lost Treasures: Understanding and Finding Memory Leaks
Posted: October 10, 2011 Filed under: .NET, Java, Performance | Tags: alloc, allocations, App, Apps, CLR, Dispose, Dynatrace, Free, Garbage, GC, Heap, Java, JVM, mem, Memory, Monitoring, Notes, Optimizations, Optimize, PDF, Perf, perfmon, Performance, Runtime, Stack, Virtual Leave a comment »By dynaTrace
Memory leaks – together with inefficient object creation and incorrect garbage collector configuration – are the top memory problems
We need a heap analyzer for analyzing heap content and a console to collect and visualize runtime performance metrics.
A central concept in understanding the origins of memory leaks is Garbage Collection roots. A GC root is a reference which only has outgoing and no incoming references. Every object on the heap has at least one GC root. If an object is no longer referenced by a GC root it is marked as unreachable and ready for Garbage Collection.
There are three main types of GC roots.
• Temporary variables on stack of threads
• Static fields of classes
• Native references in JNI
Collections are the critical part here as they allow us to grow continuously over time, while holding an ever-increasing number of references. So this means that most memory leaks are caused by collections which are directly or indirectly referenced by static fields.
In memory analysis you will in this context often hear about the concept of dominators or the dominator tree. The concept of a dominator comes from graph theory and is defined as follows:
A node dominates another node if it can only be reached via this node. For memory management this means that A is a dominator of B if B is only referenced by A. A dominator tree is then a whole tree of objects where this is true for the root object and all referenced objects.
In case there are no more references to a dominator object all referenced objects will be freed up as well. Large dominator trees are therefore good candidates for memory leaks.
The general advice is to work with smaller heaps.
A good test is to create a heap dump from a production-sized instance and calculate the GC size of all HTTP sessions. In case you have problems solving this simple problem, you should either upgrade your tooling or decrease your heap size. Otherwise you might end up in a situation where you have no means to diagnose a memory leak in your application.
