When memory leak detection does not spot any abnormal data structure growth that looks like a memory leak, the second line of defense is set to capture OutOfMemoryError events and analyze the contents of memory when such an event occurs. When the event is captured, the native code of the Plumbr Agent captures the snapshot of statistics from JVM memory and sends it to the Plumbr Server for analysis. When the analysis completes, an incident is created containing the following information:

  • What are the “fattest” data structures currently in memory (measured in MB).
  • What is currently referencing such data structures, blocking them from being GC-d.
  • Of what do these “fat” data structures consist.
  • Where were these data structures created.

Having this information allows you to quickly understand the most likely reason why the OutOfMemoryError was triggered. In the vast majority of cases, the culprit is staring right at you in one of the top three memory consumers.

The information might look somewhat similar to the dominator tree one could acquire via heap dumps, but at a closer look you will see that Plumbr exposes a lot more information than one could capture via heap dumps (such as the allocation points and the full reference chain). In addition, the relevant information is presented in a lot more user-friendly way, saving you from days spent trying to figure out why some byte arrays seem to occupy most of the heap inside your heap dumps.