I can't find them documented anywhere. So what does the values in this Logcat error message mean:
06-28 14:59:53.172: E/dalvikvm(32679): 32679(...) stat: (e) 393 5941KB / (c) 0 0KB / (a) 27 69MB / (h) 730KB 2668KB 1937KB
I should additionally mention that after this message I got this:
06-28 14:59:53.172: D/dalvikvm(32679): GC_FOR_ALLOC freed 2050K, 65% free 4916K/13892K, paused 26ms, total 26ms
From Android Documentation :
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>,
<External_memory_stats>, <Pause_time>
Example :
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 64% free 3571K/9991K,
external 4703K/5261K, paused 2ms+2ms
All fields name are self-explainatory, but some points to note :
freed 2049K - this is amount of live object freed by GC in this run
64% free 3571K/9991K - 64% of 9991K which = 6494K amount is free and 36% is live object size
Related
I have exit my app, but there is still a backgroud service is running. Whe the GC logs come a log. I will so you the logs beblow. You can see, about 3 logs per second. Is This phenomenon is normal ? My device's memory is enough, and the backgroud service is holding a WebSocket connection.
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
08-11 10:33:54.776 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1985K, 18% free 10676K/12871K, paused 12ms+8ms, total 54ms
08-11 10:33:55.109 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1950K, 18% free 10671K/12871K, paused 12ms+17ms, total 68ms
08-11 10:33:55.459 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2004K, 18% free 10680K/12871K, paused 13ms+8ms, total 62ms
08-11 10:33:55.769 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2010K, 18% free 10680K/12871K, paused 12ms+7ms, total 48ms
08-11 10:33:56.093 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+9ms, total 50ms
08-11 10:33:56.416 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 2ms+8ms, total 37ms
08-11 10:33:56.746 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10682K/12871K, paused 8ms+8ms, total 46ms
08-11 10:33:57.079 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:57.429 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2002K, 18% free 10678K/12871K, paused 12ms+19ms, total 59ms
08-11 10:33:57.766 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2003K, 18% free 10679K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:58.143 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1945K, 18% free 10669K/12871K, paused 12ms+17ms, total 72ms
08-11 10:33:58.473 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 2ms+6ms, total 41ms
08-11 10:33:58.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2013K, 17% free 10690K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.106 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10683K/12871K, paused 12ms+8ms, total 53ms
08-11 10:33:59.443 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2021K, 18% free 10681K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 11ms+7ms, total 44ms
08-11 10:34:00.153 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1997K, 18% free 10677K/12871K, paused 12ms+18ms, total 58ms
Is This phenomenon is normal ?
It depends what you mean by "normal".
If you mean normal for an application with those particular heap dimensions, that amount of heapspace used for long-lived objects, and that rate of allocation ... then the answer is "Yes, it is normal".
Basically, you are running your application with a heap that is (objectively) too small for the work that you are asking it to do. You have roughly 2Mb of free space, and you are allocating objects at roughly 6Gb per second. If you want to reduce the number of GC cycles, you need to do one or more of the following:
Increase the heap size. (I don't know if this is feasible for an Android app ...)
Reduce the "working set" of long-lived objects. Maybe you have a memory leak, lots of large images loaded, or an overly large in-memory cache of ... something.
Reduce the rate at which new objects are being allocated by your application.
The last two require you to track down the source of the memory usage / allocation, and change you code to mitigate the effects. There are tools (memory profilers) that can help with this, but the details will be specific to your application.
Here's how I'd interpret the GC log lines ... by example:
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕
GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
The "GC_CONCURRENT" collector is being used.
This GC collection cycle reclaimed 2020K bytes.
When the GC cycle completed, 18% of the heap is free, and 10682K out of a total usable heap size of 12871K is in use.
Normal thread activity was paused for two intervals of 12ms and 6ms respectively.
The elapsed time for the GC cycle was 44ms.
Note that the amount of heap freed isn't always exactly the same as the different between total and available ... because for much of the time that the GC is running there are normal threads allocating new objects.
I am making an app that involves a lot of animation.
For example:
I got a group of png files(50+) and iterate them with the frame rate of 15fps, to make it looks like an animation.
I have many groups of image files like that. image size: 480x800, with alpha.
my app works basically okay, while I found a lot of GC_FOR_ALLOC in the logcat while playing animation.
my question is that with so many GC_FOR_ALLOC, can I just ignore them, or figured someway to eliminate them? my app also has an minor problem, not sure if related with GC, on some older android devices, the frame rate can not get to even 10fps.
I tried to recycle the bitmap, but it seems only mark that item is available for GC.
I load image this way:
BitmapFactory.Options localOptions = new BitmapFactory.Options();
localOptions.inPreferredConfig = Bitmap.Config.ARGB_8888;
try {
return BitmapFactory.decodeStream(context.getAssets().open(fileName), null, localOptions);
} catch (IOException e) {
e.printStackTrace();
}
return null;
after load the image, I draw them on SurfaceView, like this:
canvas.drawBitmap(BgImage,rectBG2, rectScreen2, null);
for every frame, I need to draw about 3 images(3 layers). not sure if that has anything to do with GC.
below is an example of those GCs:
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17653K/32583K, paused 29ms, total 29ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17653K/32583K, paused 25ms, total 25ms
E/ttt ( 4993): 64
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 25ms, total 25ms
E/ttt ( 4993): 64
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 37ms, total 37ms
E/ttt ( 4993): 83
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 37ms, total 38ms
E/ttt ( 4993): 68
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 25ms, total 26ms
E/ttt ( 4993): 53
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 25ms, total 26ms
E/ttt ( 4993): 62
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 67
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 67
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 65
currently I am trying a way to load bitmap from JNI, like game engine did, not sure if this is the right way to do it.
While your app should run fine with those, I would say your best bet is to look into getting rid of them. Remember that this means your app is having to constantly free resources, which is time-consuming for your app (when it's running that much), and also bad from a memory management perspective. You can see a bit more about this here: https://stackoverflow.com/a/11312145/3342157 While you may not have any issues now, it could potentially cause major slowdowns later (if it isn't already).
As for how to get rid of them, remember that you should only have to reload the image if you are changing it. If you aren't, I would say to not reload it each frame. If you have several images it will swap between and can afford to use the memory (not sure on the image sizes), load them all at the beginning, and then hold on to them for rendering later. I see that you are specifically talking about animation, and my recommendation would be to create a sprite sheet to prevent having to load each individual PNG image.
I have got a problem which is driving me wild. I used Google Map API V2 in my Code and when I'm moving the map I can see the following Logcat output (on Nexus 7):
01-23 21:17:10.724: D/dalvikvm(5484): GC_FOR_ALLOC freed 4531K, 21% free 12911K/16312K, paused 29ms, total 29ms
01-23 21:17:10.724: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.043MB for 285724-byte allocation
01-23 21:17:10.744: D/dalvikvm(5484): GC_FOR_ALLOC freed 200K, 22% free 12990K/16592K, paused 25ms, total 25ms
01-23 21:17:12.074: D/dalvikvm(5484): GC_FOR_ALLOC freed 1326K, 23% free 12893K/16592K, paused 30ms, total 31ms
01-23 21:18:04.854: D/dalvikvm(5484): Debugger has detached; object registry had 1 entries
01-23 21:18:07.374: D/dalvikvm(5484): GC_FOR_ALLOC freed 658K, 23% free 12904K/16592K, paused 27ms, total 27ms
01-23 21:18:07.384: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.763MB for 1048592-byte allocation
01-23 21:18:07.404: D/dalvikvm(5484): GC_FOR_ALLOC freed 2K, 21% free 13925K/17620K, paused 27ms, total 27ms
01-23 21:18:07.714: D/dalvikvm(5484): GC_FOR_ALLOC freed 2127K, 26% free 13054K/17620K, paused 29ms, total 29ms
01-23 21:18:44.694: D/dalvikvm(5484): GC_CONCURRENT freed 1894K, 27% free 12970K/17620K, paused 4ms+5ms, total 56ms
01-23 21:18:46.684: D/dalvikvm(5484): GC_CONCURRENT freed 1738K, 27% free 12996K/17620K, paused 4ms+2ms, total 53ms
01-23 21:18:49.254: D/dalvikvm(5484): GC_CONCURRENT freed 1756K, 27% free 13014K/17620K, paused 2ms+8ms, total 77ms
01-23 21:18:56.864: I/dalvikvm(5484): Jit: resizing JitTable from 8192 to 16384
01-23 21:18:56.934: D/dalvikvm(5484): GC_CONCURRENT freed 1840K, 21% free 13010K/16312K, paused 2ms+4ms, total 49ms
01-23 21:18:59.434: D/dalvikvm(5484): GC_CONCURRENT freed 1779K, 21% free 12995K/16312K, paused 4ms+5ms, total 50ms
01-23 21:19:03.414: D/dalvikvm(5484): GC_CONCURRENT freed 1781K, 21% free 13007K/16312K, paused 2ms+3ms, total 48ms
The heap keeps growing and growing and I have no idea what I can do about it. I searched through the web and through stackoverflow, but there was no helpful answer for me.
I hope someone of you can find the error. I am very new to Android, so please appreciate.
EDIT1: Heap Dump:
EDIT2: MAT Analysis
Suspect 1:
One instance of "maps.by.a" loaded by "dalvik.system.PathClassLoader # 0x4480cfa8" occupies 1.002.352 (22,33%) bytes. The memory is accumulated in one instance of "maps.by.d" loaded by "dalvik.system.PathClassLoader # 0x4480cfa8".
Keywords
maps.by.a
dalvik.system.PathClassLoader # 0x4480cfa8
maps.by.d
Suspect 2:
3.507 instances of "java.lang.Class", loaded by "<system class loader>" occupy 795.104 (17,72%) bytes.
Biggest instances:
•class com.ibm.icu4jni.util.Resources$DefaultTimeZones # 0x401fccc8 - 151.744 (3,38%) bytes.
•class android.text.Html$HtmlParser # 0x4016d288 - 126.592 (2,82%) bytes.
•class org.apache.harmony.security.fortress.Services # 0x40091188 - 51.456 (1,15%) bytes.
Keywords
java.lang.Class
Suspect 3:
8.168 instances of "java.lang.String", loaded by "<system class loader>" occupy 529.048 (11,79%) bytes.
Keywords
java.lang.String
First, your heap doesn't "keep growing". It is hovering between 12893K and 13054K, rising and falling, with one outlier peak at 13925K. Personally, I don't see anything in that log that would worry me.
Regarding your MAT output, if those are the three top culprits, none are surprising. The latter two say "I am writing an app for Android", as those are always there on any Android app. The first one indicates that Maps V2 has one rather pudgy object. Again, I see nothing in that output that would suggest a problem.
I am trying to setup a android virtual device to test syncing with an activesync-server.
I followed these steps:
The problem is that syncing is not working at all, but there are no errors like connection errors ...
IMO the problem is that the virtual device only has a private IP, so the server never can send anything to it?
So I probably need some kind of forwarding, like here:
But I am not sure if that’s correct and I am also not sure which ports should be forwarded.
Here is the logcat, when I want to sync:
W/InputMethodManagerService( 148): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy#41302038 attribute=null
I/Choreographer( 274): Skipped 41 frames! The application may be doing too much work on its main thread.
D/dalvikvm( 477): GC_CONCURRENT freed 396K, 6% free 8392K/8903K, paused 15ms+7ms, total 527ms
D/dalvikvm( 274): GC_CONCURRENT freed 360K, 11% free 9493K/10567K, paused 29ms+48ms, total 142ms
I/EAS ContactsSyncAdapterService( 477): Contact sync requested for test#example.com
D/dalvikvm( 148): GREF has increased to 601
D/dalvikvm( 477): WAIT_FOR_CONCURRENT_GC blocked 0ms
I/Choreographer( 274): Skipped 33 frames! The application may be doing too much work on its main thread.
D/dalvikvm( 477): GC_EXPLICIT freed 333K, 7% free 8355K/8903K, paused 78ms+32ms, total 1269ms
I/EAS EmailSyncAdapterService( 477): performSync
I/EAS EmailSyncAdapterService( 477): Mail sync requested for test#example.com
D/dalvikvm( 460): WAIT_FOR_CONCURRENT_GC blocked 0ms
D/dalvikvm( 460): GC_EXPLICIT freed 216K, 5% free 8483K/8839K, paused 145ms+94ms, total 914ms
D/dalvikvm( 148): WAIT_FOR_CONCURRENT_GC blocked 0ms
D/dalvikvm( 148): GC_EXPLICIT freed 510K, 7% free 11338K/12167K, paused 8ms+35ms, total 323ms
D/dalvikvm( 274): GC_CONCURRENT freed 415K, 11% free 9486K/10567K, paused 25ms+28ms, total 125ms
E/Inbox[test#example.com]( 477): Uncaught exception in EasSyncServicejava.lang.ArrayIndexOutOfBoundsException: length=32; index=32
E/Inbox[test#example.com]( 477): Sync ended due to an exception.
D/dalvikvm( 477): GC_CONCURRENT freed 376K, 6% free 8420K/8903K, paused 5ms+18ms, total 66ms
I don't think this is a problem with your networking setup. It looks like you have an error in your Sync code, that is causing the process to stop:
E/Inboxtest#example.com: Uncaught exception in EasSyncServicejava.lang.ArrayIndexOutOfBoundsException: length=32; index=32
E/Inboxtest#example.com: Sync ended due to an exception.
>
Wrap this code in a try/catch block to understand what is happening better.
I see a lot of this:
06-19 17:29:11.911: DEBUG/dalvikvm(10028): GC_FOR_MALLOC freed 729K, 54% free 3490K/7431K, external 0K/512K, paused 39ms
06-19 17:29:11.941: DEBUG/dalvikvm(10028): GC_FOR_MALLOC freed <1K, 49% free 3855K/7431K, external 0K/512K, paused 29ms
repeatedly in the log. Is there a way to not show the Dalvik debug messages?
Simply set a logcat filter. You can do this graphically in Eclipse as well.