leakcanary
leakcanary copied to clipboard
Memory snapshot testing library
As LeakCanary must be able to perform well on Android devices, it needs to keep a low memory footprint. Up until now, we've relied on manual profiling for identifying bottleneck. In #1878 I added snapshot tests for the number of IO reads, then realized we could do something similar for memory and ensure LeakCanary has a constant memory footprint for known inputs at each step of the analysis.
I used HeapAnalyzer in the test but it's limited in how it works, both doing too much work and not having enough flexibility.
A few random notes:
- We could compute differential footprints, ie simply go through all reachable objects and establish the total reachable memory. Then the before / after of an operation step indicates the additional memory that step takes.
- One drawback though is that there might be other things happening at the same time
- An alternative approach is to compute the retained memory for objects that can be reached only though java locals for a specific thread. This is nice for stepped single threaded computations with no side effects. Best approach is to spin off a new clean thread
- For JVM support we'll need to consider classes as part of the retained graph. On Android classes are never unloaded and are basically GC roots. In a JVM classes can be unloaded.
- Computing the total retained size is useful for snapshot test but doesn't help debugging. We might have to print a retained graph, maybe with a threshold of retained memory for branches to skip.