The trigger: we observed JVM crashes with java.lang.OutOfMemoryError.<\/p>\n\n\n\n
The goal: find a tool that can analyze large (>10 GB) heap dump files created on OOM Error, analyze them in automated way and give a binary answer whether a memory leak was detected or not.<\/p>\n\n\n\n
There are several tools on the market which claim to be able to analyze the heap dump files: Shark, VisualVM CLI, JProfiler CLI \/ YourKit CLI, IBM Heap Analyzer, JHAT, Eclipse Memory Analyzer Tool. An additional alternative is to write own analysis tool.<\/p>\n\n\n\n
The winner is Eclipse Memory Analyzer Tool.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Let’s take a look at the options we have.<\/p>\n\n\n\n
This tool is designed specifically for Android and it is not suitable for:<\/p>\n\n\n\n
Backend services<\/p>\n\n\n\n
Microservices<\/p>\n\n\n\n
JVM heap dumps<\/p>\n\n\n\n
Large heaps (GBs)<\/p>\n\n\n\n
<\/p>\n\n\n\n
Limited automation<\/p>\n\n\n\n
Small heaps only<\/p>\n\n\n\n
<\/p>\n\n\n\n
Commercial<\/p>\n\n\n\n
Very strong automation<\/p>\n\n\n\n
Excellent diff engine<\/p>\n\n\n\n
I work with YourKit tool frequently doing manual analysis (like heap utilization or memory leaks). It is very useful and powerful, but so far I have used it on living java processes.<\/p>\n\n\n\n
This tools cannot analyze .hprof files. It can dump, create and analyze snapshot files. I did not find any tool how to convert .hprof to a snapshot.<\/p>\n\n\n\n
So if we want to release automated analysis tool we have to rely on customers having JProfiler \/ YourKit.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Excellent for OpenJ9 (high-performance Java Virtual Machine (JVM) originally developed by IBM). Since I am using a different JVM, I decided not to test this solution<\/p>\n\n\n\n
CLI automation<\/p>\n\n\n\n
<\/p>\n\n\n\n
It is not supported anymore.<\/p>\n\n\n\n
<\/p>\n\n\n\n
MAT can check for specific class causing leak and will give true\/false result for this class.<\/p>\n\n\n\n
MAT can compare two hprof files.<\/p>\n\n\n\n
MAT is the winner of my tool selection. It successfully passed several of my test cases. I have not used it in production environment so far.<\/p>\n\n\n\n
<\/p>\n\n\n\n
This is extremely complex and time consuming. Below some aspects of it (I compare it to the MAT).<\/p>\n\n\n\n
JVM Heap Dumps Are Massive Graphs. A .hprof file contains:<\/p>\n\n\n\n
Millions of objects
Billions of references
Deep object hierarchies
Mixed primitive arrays, strings, classes, threads, GC roots
Example: a 1\u202fGB server heap can have 20\u201350 million objects.<\/p>\n\n\n\n
To detect leaks, we must analyze all objects’ reachability. That is literally a giant directed graph.<\/p>\n\n\n\n
Challenge: We need a memory-efficient graph representation \u2014 otherwise our analyzer will run out of memory before it finishes analyzing the heap.<\/p>\n\n\n\n
Heap dump format is tricky as .hprof files are binary files. There are:<\/p>\n\n\n\n
Multiple formats depending on VM
Object ID sizes differ per JVM (32-bit vs 64-bit)
Classes, fields, arrays, primitives are encoded differently
References vs primitive values require different parsing
So we need a robust, low-level parser. One small mistake = parser crashes on a 20\u202fGB heap.<\/p>\n\n\n\n
We need GC root resolution
Leaks are only defined relative to GC roots (things that are always reachable).<\/p>\n\n\n\n
Static fields
Threads
JNI references
Classloaders
We must implement:<\/p>\n\n\n\n
A system that finds all roots
Correctly identifies strong vs weak references
Tracks reachable vs unreachable objects
Otherwise, we will misreport leaks.<\/p>\n\n\n\n
Dominator tree computation is non-trivial
To find retained memory (what a leak \u201cholds\u201d):<\/p>\n\n\n\n
We must build a dominator tree of the heap graph. This involves graph algorithms on millions of nodes. Naive implementations can use hundreds of GB of RAM for large heaps. Eclipse MAT does this efficiently using memory-mapped indexes, compression, and optimized algorithms.<\/p>\n\n\n\n
Rewriting it yourself = months of careful work.<\/p>\n\n\n\n
We need retained size calculations
To detect leaks:<\/p>\n\n\n\n
We must sum memory recursively from dominator tree. Count arrays, object headers, references correctly. Handle shared subgraphs properly
Mistakes here \u2192 false positives\/negatives.<\/p>\n\n\n\n
We need scalability + stability
Our tool must handle:<\/p>\n\n\n\n
1\u202fGB \u2192 small test dumps (easy)
40\u2013100\u202fGB production dumps (hard)
Running in headless, CI\/CD environments
Parsing without crashing
Most homegrown parsers fail silently on production dumps.<\/p>\n\n\n\n
We need automation \/ reporting \/ error handling. Even if we parse the heap correctly:<\/p>\n\n\n\n
We must generate reports programmatically
Identify \u201cProblem Suspects\u201d
Handle malformed dumps
Support multiple JVM types
All this adds more complexity.<\/p>\n\n\n\n
Industry estimate And that\u2019s for a team of engineers experienced in JVM internals.<\/p>\n\n\n\n Summary JVM heaps are massive and intricate graphs Instead of writing our own parser:<\/p>\n\n\n\n We can use MAT Core + CLI automation Our work becomes hours of automation and Java code, not months of low-level engineering.<\/p>\n\n\n\n Notice: despite years of development<\/strong>, MAT is still not 100% correct:<\/p>\n\n\n\n Off-Heap Blindness: It cannot track native memory leaks (like DirectByteBuffers or JNI allocations) because they don’t live in the .hprof file.<\/p>\n\n\n\n Unreachable Objects: Automated dumps can capture “dead” objects not yet swept by GC, sometimes leading to false positives depending on the garbage collector algorithm used (e.g., ZGC or Shenandoah).<\/p>\n\n\n\n Complex Cyclic Dependencies: If objects reference each other in massive circular chains, MAT’s Dominator Tree algorithm can struggle to isolate a single root suspect.<\/p>\n\n\n\n <\/p>\n\n\n\n \ud83d\ude80 What’s Next?<\/p>\n\n\n\n
Rewriting MAT from scratch is approximately:<\/p>\n\n\n\nStep<\/td> Time estimate<\/td><\/tr> HPROF parser<\/td> 2\u20133 months (some hprof parsers can be found on GitHub)<\/td><\/tr> Graph builder + dominator tree<\/td> 2\u20133 months<\/td><\/tr> Retained size calculation<\/td> 1 month<\/td><\/tr> Leak detection heuristics<\/td> 1 month<\/td><\/tr> Testing & validation<\/td> 2\u20133 months<\/td><\/tr> Total<\/td> ~8\u201312 months<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Reasons why it is \u201cextremely complex\u201d:<\/p>\n\n\n\n
.hprof binary format is complicated and JVM-dependent
Must correctly identify GC roots
Must compute dominator trees efficiently
Must calculate retained memory precisely
Must scale to production heaps
Must generate usable, reliable reports
Bottom line: We would be basically rewriting Eclipse MAT, which has been refined over 15+ years.<\/p>\n\n\n\n
Focus on automating leak detection logic
We get all graph algorithms, retained size, dominators, and reports for free<\/p>\n\n\n\n