Now, this TreeMap looks cool. For a second it felt really awesome.

Until I started trying to use it. The giant blocks are a few big arrays, not terribly interesting. Note that I'm only displaying the first level of depth here, so every rectangle we see is a root node. All these tiny rectangles are dominated by root.

I saw views and activities being dominated by root, when I really expected them to be a part of a parent rectangle that'd be a large block in the chart.

That's weird!

So, I plugged my heap dump parser (Shark) into the Dominator tree code from perflib (source: https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:perflib/src/main/java/com/android/tools/perflib/heap/analysis/LinkEvalDominators.kt;l=36;drc=499fa43009666c0f0a686d8e21722dbea8b2ecf0)

Then I output the dominator tree as a CSV file, imported it into Google Spreadsheet, selected the 3 columns (dominated, dominator, size) and inserted a TreeMap chart.

Here's the result

LeakCanary now does incorrectly show 3 objects leaks / 40 bytes, when it should be 2 objects (Everything + Universe) and 28 bytes.

YourKit is also correct in its dominator computation.

So, at this point, I've confirmed again & again that LeakCanary's approach is broken, and now I need to figure out a fix.. Unfortunately, a quick search shows standard dominators is expensive to compute (simple algo is quadratic!).

Much to my surprise, LeakCanary is computing the correct result this time: "Everything" only retains but not "Universe", nor the answer "42". That's not what I was getting with my unit test, so I need to figure out what's different.

References are still 4 bytes here, but on an Android VM every instance has an additional shadow$_klass_ ref field and a shadow$_monitor_ int field.

Android Studio and LeakCanary seem in sync on retained size.