Uuuugh so this was a bad idea.. because now I thought deeply about the existing code and realized I probably made a dumb mistake, and I think I found an edge case that shows I never really computed dominators right.

So, let's go back to basics, why do we care about dominators in a jvm heap anyway?

I learned about dominators from reading the Android Studio code, and how it computes retained size.

An easy def is that a dominator D of a node A is a node that if removed would make A unreachable.

Hence why if you sum up the size of all the nodes that a dominator dominates, you get the retained size.

The immediate dominator is the closest dominator to the node.

I had this algorithm in my head for progressively building up dominators: do a graph traversal, first time you find a node set it's parent as dominator, then every time you find that node again you go up the dominator chain you've already built, on both the previous parent side and the new parent side, until you find a common node, that's the new dominator.

I need to re read the AS code to see if it's doing something similar or not.

Anyway, the problem is, this doesn't account for running into the original parent node from yet another spot after you've done that. At which point you're not updating the dominated node because you're not exploring it, just its parent.

I wrote a failing unit test against the dominator data structure and confirmed it's broken.

So now I need to craft a fake heap dump and confirm I compute retained size wrong.

Then check Android Studio & Yourkit, see if they got different results.

So, I made a real life example, ran the code then dumped the heap. The results are interesting.

Note "AppWatcher.objectWatcher.watch(guide)" which tells LeakCanary that HitchHiker.guide is pretend leaking and to dump the heap.

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.