Clever Geek Handbook

In Android development, what are the implications of this: "The debugger and garbage collector are currently loosely integrated."

At the very bottom of this page, debugging on the Android developer site says

The debugger and garbage collector are now loosely integrated. The VM ensures that any object the debugger knows about is not garbage collected until the debugger disconnects. This can lead to an accumulation of objects over time when attaching a debugger. For example, if the debugger sees the current thread, the associated Thread object is not garbage collected even after the thread ends.

So what are the exact implications here? I have to assume that:

  • Any call to the log inside the thread will result in the thread never being collected?
  • Any call to the log inside a method that lives on the UI thread that is called from thread X means that thread X will never be collected?
  • Any call to the log inside a method that even contains the construct of a new thread instance or runnable might not be possible for garbage collection?

If so:

  • Does this only apply if the app is explicitly marked as debug in AndroidManifest.xml?
  • Is this used even if the device is not actively connected to the debugger?
+3


source to share


1 answer


If no debugger is connected, GC works as usual. Calls to the log are not special. While the debugger is connected, there is no guarantee that any object will be collected, because the debugger may contain additional references to whatever it feels. Once the debugger is disabled, the next GC will proceed as usual and collect the objects that were previously saved. It is impossible to say for sure which objects will not be collected, since the debugger can do whatever it sees fit.



Merely reading the logcat output does not mean "there is a debugger". This refers specifically to the actual Java debugger, eg. setting breakpoints, single step.

+1


source






More articles:


All Articles