Menu
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!
998
If your app creates a lot of objects, then the Android run time (ART) environment will trigger garbage collection (GC) frequently. Android garbage collection is an automatic process which removes unused objects from memory. However, frequent garbage collection consumes a lot of CPU, and it will also pause the app.
In the common language runtime (CLR), the garbage collector (GC) serves as an automatic memory manager. The garbage collector manages the allocation and release of memory for an application. For developers working with managed code, this means that you don't have to write code to perform memory management tasks.
Generally speaking, in the presence of a garbage collector, it is never good practice to manually call the GC. A GC is organized around heuristic algorithms which work best when left to their own devices. Calling the GC manually often decreases performance.
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:
200
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
