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.

Managing

I think the difference is caused by the processor architectures used. MotoX uses Qualcomm Snapdragon S4 (ARMv7 instruction set) , Bionix used a more updated Cortex A-A53 (ARMv8 instruction set). – Infringe

@ShreyasChavan it's the 2014 Moto X so it's got a Snapdragon 801 and the Bionic (from 2011) has got a TI OMAP Cortex-A9 – Managing

The processor architectures are irrelevant. Dalvik's heap and GC were actively developed until mid-2011, when everything switched to Art development. You're probably seeing the difference that years of development can make. I know very little about Art's innards, so I can't offer any specific insights. I will point out that looking at log messages is an apples-to-oranges comparison, and the lack of Dalvik-style logging on an Art device doesn't mean that equivalent actions aren't taking place. – Liggitt

@Liggitt I figured it was probably an ART vs Dalvik thing when I really looked at it. I'd definitely like to know what's actually going on since the run time is significantly higher on the Bionic vs the others, even with somewhat similar CPU and RAM specs on the 2012 Nexus 7 – Managing

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.

Liebowitz