I'm in the final stages of implementing a game for the Android platform and have been doing some memory profiling over the past few days. Although the app is running fine within the emulator environment, I am curious to know whether the memory it's using falls within an acceptable range.
While the app has been running, I've captured lines containing details such as the following in the output window:
GC_EXTERNAL_ALLOC freed 14K, 50% free 2939K/5831K, external 2210K/2581K, paused 170ms
GC_EXTERNAL_ALLOC freed 104K, 47% free 3142K/5895K, external 3710K/4633K, paused 263ms
GC_EXTERNAL_ALLOC freed 17K, 48% free 3106K/5895K, external 6362K/6398K, paused 104ms
GC_CONCURRENT freed 98K, 46% free 3225K/5959K, external 7462K/8042K, paused 8ms+8ms
GC_EXTERNAL_ALLOC freed 172K, 47% free 3269K/6087K, external 8023K/8042K, paused 183ms
As you can see, it typically runs with about 48% free memory.
My question is basically whether this is an acceptable amount of free memory?
Thanks,
Wayne.
Related
LibGDX Game freezing and showing this in Logcat.
And is happening on Random occasions.
08-27 19:32:46.015: D/dalvikvm(12024): GC_FOR_ALLOC freed 1205K, 22% free 6961K/8816K, paused 32ms, total 32ms
08-27 19:32:58.909: D/dalvikvm(12024): GC_FOR_ALLOC freed 1201K, 22% free 6957K/8816K, paused 22ms, total 23ms
08-27 19:32:59.089: D/dalvikvm(12024): GC_FOR_ALLOC freed 1180K, 22% free 6957K/8816K, paused 23ms, total 23ms
08-27 19:32:59.279: D/dalvikvm(12024): GC_FOR_ALLOC freed 1180K, 22% free 6957K/8816K, paused 23ms, total 23ms
08-27 19:32:59.469: D/dalvikvm(12024): GC_FOR_ALLOC freed 1180K, 22% free 6957K/8816K, paused 23ms, total 23ms
After this
08-27 19:32:59.469: D/dalvikvm(12024): GC_FOR_ALLOC freed 1180K, 22% free 6957K/8816K, paused 23ms, total 23ms
repeats until the application is closed.
The Problem is Fixed. The Problem was in the code. The game was going into one infinite loop hanging the game.
It is not an error message. I don't know what your game is and how you make new allocations, but at some point your garbage collector needs to run to open up free space for new objects. Check all allocations, debug your application and try to find where exactly it gets stuck.
Sometimes a functional app does not mean that it uses the memory effectively. Check your allocations and try to reduce the amount you are using. (This is what you should do even if the app works correctly.) Searching the project and putting a breakpoint at lines that contain the keyword "new" is a good start.
Here is the official memory debugging tutorial.
What does these numbers mean below? (caught with LogCat debugger)
08-03 14:29:11.538: I/dalvikvm-heap(6514): Forcing collection of SoftReferences for 14337016-byte allocation
08-03 14:29:11.568: D/dalvikvm(6514): GC_BEFORE_OOM freed 10K, 6% free 115756K/121948K, paused 29ms, total 30ms
08-03 14:29:11.568: E/dalvikvm-heap(6514): Out of memory on a 14337016-byte allocation.
What does 121948K and 115756K mean?
Why 14337016 byte? It is ~14MB. It's impossible! I tried to load a bitmap with 14kB size.
system is trying to free unused memory in order to be able to find some more resources for your application
GC_BEFORE_OOM happens your app's running out of its heap space
more about GC_BEFORE_OOM can be found here
Numbers:
gc freed 10K, 6% is free, which is too little, so it continues deallocation further until gc reaches oom. 115756K/121948K is statistics of the heap of your application
more information about the memory can be found by watching this vid
I connect my android phone to eclipse. And I see these message from Logcat.
Can you please tell me what does is the difference between 'GC_EXPLICIT' and 'GC_EXTERNAL_ALLOC'? and what does "45% free" mean?
10-05 12:08:34.450: DEBUG/dalvikvm(813): GC_EXTERNAL_ALLOC freed 63K, 45% free 3156K/5703K, external 4113K/4348K, paused 73ms
10-05 12:08:34.480: DEBUG/dalvikvm(101): GC_EXTERNAL_ALLOC freed 55K, 40% free 5883K/9799K, external 4911K/4913K, paused 124ms
10-05 12:08:37.120: DEBUG/dalvikvm(101): GC_EXPLICIT freed 84K, 41% free 5870K/9799K, external 5745K/6078K, paused 104ms
10-05 12:08:40.099: DEBUG/dalvikvm(493): GC_EXPLICIT freed 14K, 48% free 3782K/7175K, external 1625K/2137K, paused 75ms
10-05 12:08:45.110: DEBUG/dalvikvm(188): GC_EXPLICIT freed 57K, 54% free 3203K/6855K, external 4988K/6206K, paused 78ms
10-05 12:09:05.119: DEBUG/dalvikvm(822): GC_EXPLICIT freed 349K, 46% free 3696K/6727K, external 1625K/2137K, paused 65ms
I would highly suggest giving the Memory Management video presentation from Google I/O 2011 a watch:
http://www.youtube.com/watch?v=_CruQY55HOk
At about 14 minutes in, he goes in to depth on exactly what these mean in the logcat output.
GC Explicit basically means that an app has explicitly called System.gc();
GC Concurrent is triggered when your heap starts to fill up and a Concurrent GC kicks in to hopefully clear memory before it fills up.
GC_EXPLICIT means your app has explicitly called System.gc() or the Activity Manger of Android System called System.gc()
GC_EXTERNAL_ALLOC is something more complicated.
There are some memory related to the life time of Java's object called EXTERNAL memory. Such as memory use by GPU or pixmap resources of your app. This type of memory allocating use "malloc" of stdlib to allocation heap memory but NOT allocating from the GC Heap of Dalvik, but it's also one of the "HEAP" memory. And the total size use of the HEAP must be smaller than a limit(decide by GC).
Dalvik tracking allocation of that memory.
CONDITION: usableof(GC_HEAP) + usableof(NATIVE_HEAP[external]) <= allocaionLimit
Dalvik will cause a GC for GC_EXTERNAL_ALLOC as a sideeffect when the condition above is not true.
Good day all, i have a load of images i want to display from an sdcard to a gridview. I have followed the tutorial to do this in the is link:
http://mihaifonoage.blogspot.com/2009/11/displaying-images-from-sd-card-in.html
everything works great apart the fact that when the images become a lot, it becomes really slow to populate it and scrolling is also very slow. i have tried editing the code to use the ViewHolder method but still no luck.
now, i also have used populated the images in a custom ListView without using the AsyncTask and it appears to process it faster. yeah common sense would be to just use the faster method but want to clarify somethings first. so i am asking:
is it that AsyncTask can be really slow in some cases and not ideal or thus the fact that am using a Gridview or Listview have something to do with it? any reason why? am asking this cause AsyncTask always seem to get very good favourism.
Any Other way, solutions or tips that i can make this process faster?..
Note: i would have posted my code, but its the same things as the link only that i don't use the getThumbnails() in the MediaStore query. Thanks in advance.
here is part what i get for the logcat output when its loading the images:
10-07 19:42:54.072: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2886K/5511K, external 1574K/14018K, paused 28ms
10-07 19:42:54.092: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 1574K/14018K, paused 25ms
10-07 19:42:54.122: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 1574K/14018K, paused 25ms
10-07 19:42:54.142: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 1574K/14018K, paused 24ms
10-07 19:42:54.172: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 1574K/14018K, paused 25ms
10-07 19:42:54.202: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 1574K/14018K, paused 25ms
10-07 19:42:54.232: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 28ms
10-07 19:42:54.252: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 24ms
10-07 19:42:54.282: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 24ms
10-07 19:42:54.302: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 25ms
10-07 19:42:54.332: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 25ms
10-07 19:42:54.362: DEBUG/dalvikvm(20291): GC_EXPLICIT freed <1K, 48% free 2918K/5511K, external 14018K/14018K, paused 25ms
It is slow because in fact you are still using one single thread (i.e. one AsyncTask.execute() call) download all images in sequence (i.e. loop all image download in your doInBackground() implementation). Yes, this is the way that google suggested how to use AsyncTask.
By calling several AsyncTask.execute() will probably speed you up, this gives you several thread running simultaneously and managed by underlying thread pool (before API level 11, this thread pool is non accessible). of cause, you need somehow split your download task into several piece and feed each piece into each AsyncTask.execute():
for (DownloadTask task : tasks) {
new AsyncTask.execute();
}
Check out here for more information.
The right way to speed this up would be to use a image cache. Google has a guide for an easy implementation right here:
I'm trying to explore the behavior of the new concurrent garbage collector in GingerBread (2.3).
Could someone please explain these example log lines in details (especially the "paused" parts of GC_CONCURRENT and GC_FOR_MALLOC)?
12-24 10:20:54.912 D/dalvikvm( 414): GC_CONCURRENT freed 510K, 57% free 2529K/5831K, external 716K/1038K, paused 8ms+5ms
12-24 10:20:54.963 D/dalvikvm( 414): GC_FOR_MALLOC freed 510K, 57% free 2529K/5831K, external 716K/1038K, paused 47ms
GC_CONCURRENT Heap is (almost) full. Therefore concurrent GC kicks in
freed 510K - Amount of memory freed
57% free - Memory after freeing %
2529K/5831K - Actual mem in heap
external 716K/1038K - Externally allocated memory (memory that is not in dvm)
paused 8ms+5ms - time taken for GC
especially the "paused" parts
For concurrent collections there are two pause times. One is at the beginning of the collection and other towards the end. For non-concurrent collection there will be only one pause time.
if you haven't yet, check out this video:
http://www.google.com/events/io/2011/sessions/memory-management-for-android-apps.html