py - Pierre Yves Ricau

A memory leak is a bug where references are not properly updated, which causes objects to be strongly reacheable from gc roots (and therefore not garbage collectable) when they shouldn't....

Once a leak / bad reference is identified, we can easily find all the "leaking objects" i.e. all objects that be GCed if that ref is cleared (note: BLeaks paper...

However, finding the bad ref is the hard part. There's nothing distinguishing it from any other good ref. However, we know that any "leaking" object would be GCed if the...

So finding a leak takes a few steps: first, finding leaking objects. Then, find a path (ie one, doesn't have to be all) from gc roots to leaking object. The...

Latest thoughts: LeakCanary Internals Start with definitions Maybe worth defining watched vs retained vs leaking? if possible Add a few notes pointing to lower bus factor + helping others onboard....

This blog is gold: http://memoryanalyzer.blogspot.com/2010/02/heap-dump-analysis-with-memory-analyzer.html

We should also compare with Yourkit.

LeakCanary disables any automatic self setup in unit tests, however you're calling its APIs directly. It's harder for LeakCanary to provide guarantees there. We could always add more checks of...

Note: do not merge until we've proven the internal fix works (currently does not)

Maybe we can have something similar for executors as well.