Near the very bottom of this page about Debugging on the Android developer site it says
The debugger and garbage collector are currently loosely integrated. The VM guarantees that any object the debugger is aware of is not garbage collected until after the debugger disconnects. This can result in a buildup of objects over time while the debugger is connected. For example, if the debugger sees a running thread, the associated Thread object is not garbage collected even after the thread terminates.
So what are the precise implications here? Am I to assume that :
- Any Log call inside a thread will cause that thread to never be collected?
- Any Log call inside a method that lives in the UI thread, that is called from within thread X means that thread X will never be collected?
- Any log call inside a method that even contains the construction of a new instance of thread or runnable might be impossible to garbage collect?
If this is true :
- Does this apply only if the application is explicitly marked as debuggable in the AndroidManifest.xml?
- Does it apply even if the device is not actively connected to a debugger?
Unless a debugger is currently attached, GC runs as normal. Calls to Log are not special in any way. While a debugger is attached, there are no guarantees that any object will be collected, because the debugger may be holding extra references to anything it feels like. Once the debugger disconnects the next GC will happen as normal and collect the objects that were preserved before. It’s not possible to say exactly which objects will not be collected as the debugger can do whatever it thinks it needs to.
Just reading logcat output is not “having a debugger attached”. It refers specifically to the actual Java debugger, e.g. setting breakpoints, single stepping.