Where we were on 9 November
===========================

Convinced that dominator approach will yield results. The "real root", ie the cause of most
of the memory retention will tend to move higher in the dominator tree, probably to just below
the top root. Also finding the biggest root will be quicker because it ony takes one pass of
the dominator tree which is a true tree (no cross or down branches).

So first we do a pass to find the actual roots of the graph via the strong component approach.
By utilizing the new intermediate file approach we can generate a file with this additional
info in. The roots will be denoted in their flag byte. This saves time when experimenting
because we can skip the sc finding. (And scanning the intermediate file is a LOT quicker, 7
seconds as opposed to 3 minutes).

Then we find the dom tree. Then for each actual root, we do a single dfs in the dom tree and
choose the biggest. This must work?

Dom tree stuff - don't need the path compression part of the find ancestor with lowest semi, it
hardly makes any difference but has a significant memory overhead.

Graph reduction - was in the middle of writing little filters to do stuff on the intermediate
file. (Note: is DataOutputStream format optimum? Also maybe use C code). Next thing would be
to reduce the size by pruning leaves. Roots in the unpruned tree are roots in the pruned tree
and getting rid of the noise could save a lot of processing time.

Need output/presentation filters to take result intermediate file and output it. Maybe
pruning below a certain depth should be the job of a different filter. Mix and match.

Need examples of previous problems solved with HeapRoots/FindRoots.

In the middle of implementing clear in TreeBitSet (rename!). This is for prune logic.

Put under CVS control!
