android GC

 dalvikvm  D  GC_FOR_MALLOC freed 665 objects / 239992 bytes in 71ms
 dalvikvm  D  GC_FOR_MALLOC freed 673 objects / 240288 bytes in 87ms
 dalvikvm  D  GC_EXPLICIT freed 4802 objects / 185320 bytes in 78ms
 dalvikvm  D  GC_FOR_MALLOC freed 666 objects / 240536 bytes in 63ms

 

GC_EXPLICIT means that the garbage collector has been explicitly asked to collect, instead of being triggered by high water marks in the heap. Happens all over the place, but most likely when a thread is being killed or when a binder communication is taken down.

GC_FOR_MALLOC means that the GC was triggered because there wasn't enough memory left on the heap to perform an allocation. Might be triggered when new objects are being created.

There are a few others as well:

GC_CONCURRENT Triggered when the heap has reached a certain amount of objects to collect.

GC_EXTERNAL_ALLOC means that the the VM is trying to reduce the amount of memory used for collectable objects, to make room for more non-collectable.

GC_MALLOC, 內存分配失敗時觸發
GC_CONCURRENT，當分配的對象大小超過384K時觸發
GC_EXPLICIT，對垃圾收集的顯式調用(System.gc)
GC_EXTERNAL_ALLOC，外部內存分配失敗時觸發

 

typedef enum {
    /* Not enough space for an "ordinary" Object to be allocated. */
    GC_FOR_MALLOC,
    /* Automatic GC triggered by exceeding a heap occupancy threshold. */
    GC_CONCURRENT,
    /* Explicit GC via Runtime.gc(), VMRuntime.gc(), or SIGUSR1. */
    GC_EXPLICIT,
    /* GC to try to reduce heap footprint to allow more non-GC'ed memory. */
    GC_EXTERNAL_ALLOC,
    /* GC to dump heap contents to a file, only used under WITH_HPROF */
    GC_HPROF_DUMP_HEAP
} GcReason;

 

Roughly speaking, the format is [Reason] [Amount Freed], [Heap Statistics], [External Memory Statistics], [Pause Time]

Reason

Robert/yuku already gave info on the meaning of these.

Amount Freed

E.g. freed 2125K

Self explanatory

Heap Statistics

E.g. 47% free 6214K/11719K

These numbers reflect conditions after the GC ran. The "47% free" and 6214K reflect the current heap usage. The 11719K represents the total heap size. From what I can tell, the heap can grow/shrink, so you will not necessarily have an OutOfMemoryError if you hit this limit.

External Memory Statistics

E.g external 7142K/8400K

Note: This might only exist in pre-Honeycomb versions of Android (pre 3.0).

Before Honeycomb, bitmaps are allocated external to your VM (e.g. Bitmap.createBitmap() allocates the bitmap externally and only allocates a few dozen bytes on your local heap). Other examples of external allocations are for java.nio.ByteBuffers.

Pause Time

If it's a concurrent GC event, there will be two times listed. One is for a pause before the GC, one is for a pause when the GC is mostly done. E.g.paused 3ms+5ms

For non-concurrent GC events, there is only one pause time and it's typically much bigger. E.g.paused 87ms

 

GC_EXTERNAL_ALLOC freed 297K, 49% free 3411K/6663K, external 24870K/26260K, paused 83ms

前面Free的內存是VM中java使用的內存，external是指VM中通過JNI中Native的類中的malloc分配出的內存，例如Bitmap和一些Cursor都是這麼分配的。
在 Davilk中，給一個程序分配的內存根據機型廠商的不同，而不同，現在的大部分的是32M了，而在VM內部會把這些內存分成java使用的內存和 Native使用的內存，它們之間是不能共享的，就是說當你的Native內存用完了，現在Java又有空閒的內存，這時Native會重新像VM申請，而不是直接使用java的。
例如上邊的例子
free 3411K/6663K和external 24870K/26260K
如果這時需要創建一個2M的Bitmap，Native現有內存26260-24870=1390K<2048k,因此他就會向Vm申請內存，雖然java空閒的內存是
6663-3411=3252>2048,但這部分內存Native是不能使用。
但是你現在去申請2M的Native內存，VM會告訴你無法分配的，因爲現在已使用的內存已經接近峯值了32M(26260+6663=32923 )，所以現在就會成force close 報OOM。
所以現在我們要檢查我們的native內存的使用情況來避免OOM。

 

 

Reference :

http://stackoverflow.com/questions/4976566/what-do-gc-for-malloc-gc-explicit-and-other-gc-mean-in-android-logcat

http://stackoverflow.com/questions/4525743/what-are-the-paused-values-in-gc-concurrent-log-messages

http://hi.baidu.com/qmiao128/blog/item/69f2fa31d4a5d3b05fdf0ed2.html