16

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
Bart Friederichs
  • 33,050
  • 15
  • 95
  • 195
Rui Campião
  • 306
  • 1
  • 3
  • 10
  • Quite hard to debug your code without your code. – Bart Friederichs Dec 11 '13 at 11:32
  • 1
    If you use Google Maps for instance, you get a lot of these messages without any chance of doing anything about it. I use a filter on the messages (by Log Message): ^(?!.*(GC_)|(Cache)).*$ – cYrixmorten Dec 11 '13 at 11:35
  • Are you instantiating an object inside a loop? – leandrocastelli Dec 11 '13 at 11:50
  • In the first XML yes I instantiate Scanner(s) inside a loop so I can parse the lines one by one, but that one it's not the worst "issue". In the second one I "deserialize" with the SimpleXML framework, don't know the code, but I figure that if one parses an XML, it will have to make some instances. – Rui Campião Dec 11 '13 at 13:58
  • I am not using google maps. Waht I'm trying to know is if there is something very wrong and obvious. – Rui Campião Dec 11 '13 at 14:04
  • Bart Friederichs, what code do you want? The deSerialize process is from the SimpleXML. There are about 200 lines as I said, which turn into an object with an hierarchy of objects inside it. – Rui Campião Dec 11 '13 at 14:10
  • And also, if anyone could please tell me what you know about what really does the IC_FOR_ALLOC, I would be very pleased. – Rui Campião Dec 11 '13 at 15:40
  • Did you find any solution to hide these GC_FOR_ALLOCs?! – Dr.jacky Oct 21 '15 at 05:29
  • I am not 100% sure what was causing all this. What I remember is that I was using a library which (as it seems) wasn't very eficient for parsing XML data. I stopped using that library (in fact, I avoid almost every one that I can), chaged the data representation to JSON and parsed it myself and it became MUCH faster and solved this memory problems. – Rui Campião Oct 27 '15 at 18:40

6 Answers6

10

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.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • 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! – Rui Campião Dec 11 '13 at 17:17
  • 1
    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. – fadden Dec 11 '13 at 19:05
6

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.

QJGui
  • 907
  • 8
  • 10
2

you can use MAT MAT tutorial

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

nitesh goel
  • 6,338
  • 2
  • 29
  • 38
  • 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 Dec 11 '13 at 14:06
2

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

     }
}
ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152
jonh
  • 21
  • 1
1

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.

ZhanZF
  • 26
  • 3
  • 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! – Rui Campião Feb 17 '15 at 17:58
0

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.

Fortran
  • 2,218
  • 2
  • 27
  • 33