Fixing Message memory leaks

[pyricau]

Prior to Android L, the VM caches stack local variables in blocking loops. This can lead to memory leaks of messages for threads that become inactive but aren't shutdown. This change ensure that we never leak for too long and always replace the leaking reference.

These memory leaks tend to be problematic when using Picasso in an app that also uses Dialogs, because Dialogs obtain template Message instance that are never recycled. These messages are listeners and often hold references to the activity. When the dialog is GCed, the messages should be GCed too but they aren't because of the thread stack local message leak.

[rahulrj]

I have few questions on this @pyricau . I have also asked these questions on your blog here

1. For this leak why is a BlockingQueue required? Is this because if its not a blocking operation, then the Thread also will be garbage collected?
2. Also here Fixing Message memory leaks #932, you wrote in the description “….memory leaks of messages for threads that become inactive but aren’t shutdown”. But if a thread is inactive, then wont it be Gced along with the message?
3. Also its written that “….Prior to ART, a thread waiting on a blocking queue will leak the last dequeued object as a stack local reference.” But the following code also exists in the latest version of Android in Looper class.

for (;;) {
    Message msg = queue.next(); // might block
    if (msg == null) {
        return;
    }
    msg.target.dispatchMessage(msg);
    msg.recycleUnchecked();
}

So shouldn’t the leak be reproducible on latest version of Android also?

[seekforwings]

@rahulrj I think you should have the 'Debuggable in 'Project Structure' -> 'Build Types' being set to true for the debug mode. Change it to false and retry on the art device.