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

Solution 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.

Solution 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.

Solution 3

you can use MAT MAT tutorial

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

Solution 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

     }
}

Solution 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.

View more solutions

Comments

[Rui Campião]

Thanks, I'll try it. I must say that I am using the emulator, I can't install the drivers because I'm not the admin, and the admin didn't manage to install it for my Nexus S (it's a bit tricky). It may have to do with the problem?

[Rui Campião]

I've already used it and there isn't enough objects to make 300 consecutive frees of 344Kb nor I can instantiate such "huge" objects (in this context) on my program. There must be something else. The fact I am using the emulator can be the reason? Thank you fadden!

[fadden]

The allocation tracker only shows the most-recent 512 allocations for the selected application. If you grab a snapshot of the busy app while it's churning away you should be able to get a sense for what all is being allocated. Also, make sure you're watching the right app -- compare the process ID in the log file (6759 in your example) to what's shown on the "info" panel for the app.

[Rui Campião]

Thanks for you concern, but there was nothing like that. The way Dalvik VM works causes that. I wrote this question some time ago so I can't remember very well what was happening. What I can say is that memory is a real issue in Android, we should always be VERY careful!