leakcanary icon indicating copy to clipboard operation
leakcanary copied to clipboard

Memory snapshot testing library

Open pyricau opened this issue 5 years ago • 0 comments

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.

pyricau avatar Sep 06 '20 07:09 pyricau