Android Garbage Collector Freed Memory

Question

I'm working on an app that handles a lot of allocations (on the order of 4 million doubles and a million classes). I was looking through garbage collector logs and I'm seeing different amounts of memory total being freed across different devices.

For example, I have a Moto X (2014) that ends up freeing just over 312 MB. I also have a Droid Bionic running the same code on the same data that frees 616 MB on average. Both devices end up with a heap size of about 50 MB.

Why is so much more memory freed by the GC on the Bionic than the Moto X? They should generate the same amount of garbage each. What's going on behind the scenes in the garbage collector? The Moto X is on Android 5.1 and the Bionic is on 4.1.2.

Edit: I have four devices that are freeing about 300 MB RAM: the Moto X (2014), Nexus 7 2013, Nexus 7 2012, and Razr i. All four of these use ART. The Bionic is running the Dalvik runtime. Is this why there's less freeing up? I noticed GC_FOR_ALLOC doesn't happen in ART but is getting called all the time on Dalvik.

Answer 1

Quoting from this post:

Next, the ART team worked to optimize the garbage collector (GC). Instead of two pauses totaling about 10ms for each GC in Dalvik, you'll see just one, usually under 2ms. They've also parallelized portions of the GC runs and optimized collection strategies to be aware of device states. For example, a full GC will run only when the phone is locked and user interaction responsiveness is no longer important. This is a huge improvement for applications sensitive to dropped frames.

What the author says here is that ART powered devices will be much more efficient in context of GC - both with respect to the time GC "wastes" and the amount of memory freed at runtime.

Additional contribution to the lower memory usage can be attributed to this (this is just a guess):

In perhaps the most important improvement, ART now compiles your application to native machine code when installed on a user's device. Known as ahead-of-time compilation, you can expect to see large performance gains as the compilers are tuned for specific architectures (such as ARM, x86, or MIPS). This eliminates the need for just-in-time compilation each time an application is run. Thus your application will take slightly longer to install but will boot faster upon launch as many tasks executed at runtime on the Dalvik VM, such as class and method verification, have already taken place.

Since ART compiles your app ahead of time, the time of compilation can be extended, thus allowing the compiler to perform a better job optimizing your code.