Technical details of Android Garbage Collector
As I'm doing a research on commonalities/differences of various mobile platforms, one of the aspects under investigation is memory management. As such, I'm interested in more detailed technical information on the various mechanisms.
In specific, e.g. which garbage collector type does Android use?
([Google Groups Discussion] suggests that it is using "tracing" mechanism - but I'd appreciate a "more official" source which I could possibly quote, plus hoping to find information there which implications the type could have on the programmer).
Also among my questions is in what way the GC in Android 3.0 (Honeycomb) has been tweaked specifically to utilize multiple processors?
[Android Devevelopers Guide] suggests that
Android 3.0 is the first version of the platform designed to run on either single or multicore processor architectures. A variety of changes in the Dalvik VM, Bionic library, and elsewhere add support for symmetric multiprocessing in multicore environments. These optimizations can benefit all applications, even those that are single-threaded. For example, with two active cores, a single-threaded application might still see a performance boost if the Dalvik garbage collector runs on the second core. The system will arrange for this automatically."
As before, I'd rather find a source with more technical information to read upon this. Again, what's the impact on the developer (other than the obvious that increased performance could be hoped for)?
Any such input is appreciated.
Thanks!
Solution 1:
To answer one of your questions, the Dalvik VM indeed does use a tracing garbage collector, using a Mark and Sweep approach.
According to The Dalvik Virtual Machine Architecture:
The current strategy in the Dalvik garbage collector is to keep mark bits, or the bits that indicate that a particular object is “reachable” and therefore should not be garbage collected, separate from other heap memory.
From Android 5.0 (Lollipop) and on, Dalvik was replaced with the Android Runtime (ART).
Google has the following to say about the changes in the garbage collector from Dalvik to ART (source):
Improved garbage collection
Garbage collection (GC) can impair an app's performance, resulting in choppy display, poor UI responsiveness, and other problems. ART improves garbage collection in several ways:
- One GC pause instead of two
- Parallelized processing during the remaining GC pause
- Collector with lower total GC time for the special case of cleaning up recently-allocated, short-lived objects
- Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC_FOR_ALLOC events extremely rare in typical use cases Compacting GC to reduce background memory usage and fragmentation
See also:
- The source code of the Dalvik garbage collector
- The source code of the ART garbage collector