16

When I run my application on emulator the Logcat is showing this:

04-22 16:21:30.685: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 78ms+17ms, total 360ms

04-22 16:21:30.685: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 143ms
04-22 16:21:31.845: D/dalvikvm(967): GC_CONCURRENT freed 1552K, 20% free 7019K/8720K, paused 116ms+18ms, total 554ms

04-22 16:21:31.845: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 268ms
04-22 16:21:32.435: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 75ms+9ms, total 192ms

04-22 16:21:32.435: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 73ms
04-22 16:21:32.945: D/dalvikvm(967): GC_CONCURRENT freed 1552K, 20% free 7019K/8720K, paused 75ms+10ms, total 209ms

04-22 16:21:32.945: D/dalvikvm(967): WAIT_FOR_CONCURRENT_GC blocked 70ms
04-22 16:21:33.434: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 78ms+12ms, total 192ms

and this continues until I exit the application.Any suggestion?Thanks

DigCamara
  • 5,352
  • 4
  • 33
  • 45
melib
  • 191
  • 1
  • 1
  • 5

5 Answers5

8

Seems like you're creating many new objects and throw them away soon.

For WAIT_FOR_CONCURRENT_GC see this one: what does WAIT_FOR_CONCURRENT_GC blocked mean?

It means you try to allocate memory (for example object creation) and it doesn't fit into memory. Thats what GC_CONCURRENT freed is caused by. Its just usual garbage collection.

If you've got performance problems, try to reuse objects or spare them.

Community
  • 1
  • 1
luxer
  • 660
  • 5
  • 15
5

This means you are doing too many operations and a lot of memory is being used. Hence, GC(Garbage collector) is being called to free up memory.

04-22 16:21:30.685: D/dalvikvm(967): GC_CONCURRENT freed 1545K, 20% free 7019K/8720K, paused 78ms+17ms, total 360ms

freed indicates how much memory was freed

GC_CONCURRENT Invoked when the heap gets too large to prevent overflow.

paused 78ms+17ms – indicates how much time it took the GC to finish collection.

Refer

Additionally take memory dump and analyze the dump use MAT tool.

Sunny Kumar Aditya
  • 2,724
  • 4
  • 24
  • 38
2

Agree mostly with @luxer, but I believe it's not that you are allocating too many objects, but you are allocating some huge objects. If you refer to the link pointed by @luxer about WAIT_FOR_CONCURRENT_GC, you will realize that a second gc is being triggered in your app while a concurrent gc (which is typically triggered when the heap occupancy hits a soft limit) is in progress. The second gc could have been triggered by you explicitly or because an allocation failed. Since you have not indicated that you're calling System.gc(), I would assume that your allocations are failing and the system is trying to do a gc.

So, yeah, you should seriously consider reusing some huge objects instead of allocating them each time. This is a better practice, but if for some reason you're unable to do that, you can probably bump your heap size (by setting large heap) and that may help.

layman
  • 401
  • 3
  • 9
2

Sometimes it happens when you have a never ending loop just because some condition is always true.

Try to figure out if its this case first as it happens mostly because of this.

My God
  • 21,961
  • 23
  • 93
  • 166
0

I was able to resolve mine by debugging my code : There was a DB operation lurking in an infinite while loop, which was filling the bean and hence causing the memory leak.

Maybe if you'r a a newbie like me, please check on the while/do-while/for loops and object allocations done in loops. Un closed connections and Cursors should also be closed.

Thanks,

user2176576
  • 652
  • 2
  • 13
  • 38