Memory Debugging things D/DALVIKVM (809): Gc_concurrent freed

General Java virtual machines require support for the VERBOSEGC option to output detailed garbage collection debugging information. Dalvik virtual machines are quiet to accept the VERBOSEGC option, and then do nothing. The Dalvik virtual machine uses its own set of log mechanisms to output debug information.   If you run the ADB logcat command under Linux, you can see the following output:  D/DALVIKVM ( 745): Gc_concurrent freed 199K, 53% free 3023k/ 6343k,external 0k/0k, paused 2ms+2ms   where D/DALVIKVM represents debug information output by DALVIKVM, the number after the parentheses represents the PID of the process where the DALVIKVM is located.  gc_concurrent indicates that the cause of the garbage collection is triggered by the following: Gc_malloc, when the memory allocation fails to trigger gc_concurrent, when the allocated object size exceeds 384K, the gc_explicit is triggered, and the explicit call to garbage collection ( SYSTEM.GC) Gc_external_alloc, the external memory allocation fails when triggered freed 199K means that this garbage collection frees up 199K of memory,  53% free 3023k/6343k, where 6343K represents the total current memory, 3023K indicates available memory and 53% indicates the percentage of available memory for total memory.  external 0k/0k, which represents the total amount of available external memory/external memory  paused 2ms+2ms, the first time value represents the time of Markrootset, and the second time value represents the time of the second mark. If the trigger reason is not gc_concurrent, this behavior is a single time value that represents the time-consuming period of garbage collection.   2. Analysis   (1) Although DALVIKVM provides some debugging information, there is also a lack of key information, such as Mark and Sweep's time,  allocating memory failure because of the allocation of memory failure, and for SoftReference, WeakReference and phantomreference processing, each garbage collection processed how many of these references.   (2) currently Dalvik all threads share a memory heap, so that when allocating memory must be mutually exclusive between threads, consider allocating a thread-local storage heap for each memory, and some small memory allocations can be allocated directly from the heap without mutexes.   (3) DalviConcurrentmark is introduced in K virtual machines, but for multicore CPUs, you can implement Parrelmark, which means that you can use multiple threads to run the mark phase simultaneously. These are the improvements that Dalvik virtual machine memory management can make today.

Gc_for_malloc means that the GC is triggered because there wasn ' t enough memory left on the heap to perform an A Llocation. Might is triggered when new objects is being created.

gc_explicit means that the garbage collector have been explicitly asked to collect, instead of being triggered by High water marks in the heap. Happens all-over-the-place, if most likely-a thread is being killed or when a binder communication are taken down.

There is a few others as well:

gc_concurrent Triggered when the heap had reached a certain amount of objects to collect.

Gc_external_alloc means the the the the VM is trying to reduce the amount of memory used for collectable objects, to Make to more non-collectable.

typedefenum{
Gc_for_malloc,
Gc_concurrent,
Gc_explicit,
Gc_external_alloc,
Gc_hprof_dump_heap
}gcreason;

Gc_external_alloc freed 297K, 49% free 3411k/6663k, EXTERNAL 24870k/26260k, paused 83ms

The memory in front of free is the memory used by Java in the VM, external refers to the memory allocated by malloc in the VM through the native class in the JNI, such as bitmap and some of the cursor are so assigned.
In Davilk, the memory allocated to a program varies according to the manufacturer of the model, but the majority of the current is 32M, and in the VM will be divided into Java memory and memory used by native, they are not shared between, that is, when your native memory is exhausted Now that Java has free memory, native will re-apply as a VM instead of using Java directly.
For example, the above example
Free 3411k/6663k and external 24870k/26260k
If you need to create a 2M bitmap,native existing memory 26260-24870=1390k<2048k at this point, he will request memory from the VM, although the Java free memory is
6663-3411=3252>2048, but this part of the memory native is not available.
But now that you're applying for 2M of native memory, the VM will tell you that you can't allocate it because the memory you're using now is nearing the peak of 32M (26260+6663=32923), so now it's force close to Oom. So now we're going to check the usage of our native memory to avoid oom.

Article reprinted from: http://blog.sina.com.cn/s/blog_6610da390101bhqj.html

Memory Debugging things D/DALVIKVM (809): Gc_concurrent freed