Why so many GC_FOR_ALLOC in a simple app?

Question

I'm getting way too many GC_FOR_ALLOC from the dalvikvm. I'm getting XML from a REST service: in one activity I parse about 100 lines programatically(me) and in the other activity I use the SimpleXML to parse about 200 lines.

In the first one I get 50 GC_FOR_ALLOC. In the second one I get like 300!! (I can't even post it all, the body makes 29579 characters and it's allowed only 30k)

I've searched and almost everyone complains about gc_for_"M"alloc and not gc_for_"A"lloc.

Is the SimpleXML the problem because the instances created?

I'll post the logcat dump by dalvikvm, maybe the values have some information.

Thank you very much for your help.

12-11 06:13:49.564: D/dalvikvm(6759): GC_FOR_ALLOC freed 362K, 13% free 4116K/4688K, paused 181ms, total 182ms
12-11 06:13:50.074: D/dalvikvm(6759): GC_FOR_ALLOC freed 303K, 13% free 4134K/4708K, paused 142ms, total 142ms
.... repeated many times .....
12-11 06:14:06.254: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% free 4159K/4768K, paused 53ms, total 53ms
12-11 06:14:06.314: D/dalvikvm(6759): GC_FOR_ALLOC freed 103K, 13% free 4159K/4768K, paused 56ms, total 57ms
12-11 06:14:06.374: D/dalvikvm(6759): GC_FOR_ALLOC freed 29K, 12% free 4203K/4768K, paused 54ms, total 54ms
12-11 06:14:06.424: D/dalvikvm(6759): GC_FOR_ALLOC freed 73K, 13% fre

Answer 1

You can see the most-recently-allocated objects using the DDMS Allocation Tracker ( memory debugging docs , old blog post , ddms docs ). This will show you what's being allocated and give you a stack trace for the place where the allocation is being performed.

Another blog post describes MAT and other relevant tools, though heap-dump analysis is less useful for this sort of problem because it generally shows you the objects that haven't been freed, and you're more interested in the objects that are being freed.

Answer 2

In Android Dalvik VM, GC_FOR_ALLOC is inovked in object alloc step when dlmalloc footprint space is NOT enough for new or heap->bytesAllocated + n > hs->softLimit . You can set dalvik.system.setTargetHeapUtilization lower for more free heap space.

Answer 3

you can use MAT MAT tutorial

to find how many object are creating and garbage collected. so that youcan optimize your code

Answer 4

If you get that multiple GC_FOR_ALLOC while your app is lagging, there is a big possibility that the bug is in a loop. Check where the line of code starts to trigger the GC then start tracing the code from there. In my experience, I mistyped my inner loop iterator which causes the program to make an infinite loop. I created a bug like this:

for(int i=0; i<list.size(); i++) {
     for(int j=i+1 j<list.size(); i++) {

     // I mistyped the iterator of integer j with i
     // making an infinite loop which triggered the GC.
     //appears many times

     }
}

Answer 5

I encounter the same problem today. I find a not ended loop in my code such as while(i < xx), but I not implement the i++ statement in the while body. So the messages like you meet appeared. Check your code firstly please.

Answer 6

My log:

D/dalvikvm: GC_FOR_ALLOC freed 549K, 9% free 7878K/8596K, paused 30ms, total 34ms

...freed 539K, 9% free 7888K/8596K, paused 30ms, total 30ms
...freed 1856K, 21% free 8083K/10108K, paused 51ms, total 51ms
...freed 582K, 9% free 7845K/8596K, paused 38ms, total 38ms

Explain:

When your app get memory more limit per app. Dalvik/Ant call garbage collector.

What limits memory for your App decide Dalvik/Ant. As you see for my app Dalvik decide 8596K(double case) and 8083K(one case).

And limits change in runtime.

And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.

PS: Decide when call GC teakes Dalvik/Ant. And you can not be sure when this happens. But you can reduce the likelihood. Decreasing the amount of memory that your application consumes.

PS: In "Monitor android" see tab "Monitors", graphics "Memory". And use buttons: "pause(enabled)", Initiate GC, "Dump Java Heap" "Start Alocation Tracking(very useful)". And use official guide for this:

https://developer.android.com/studio/profile/am-memory.html?utm_source=android-studio .

As far as I understand App must not stop/pause working or crashes when VM call GC .