Memory debugging things D/dalvikvm (809): GC_CONCURRENT freed, dalvikvm

Memory debugging things D/dalvikvm (809): GC_CONCURRENT freed, dalvikvm
Generally, Java virtual machines must support the verbosegc option to output detailed garbage collection debugging information. The dalvik Virtual Machine quietly accepts the verbosegc option and does nothing. The dalvik virtual machine uses its own LOG mechanism to output debugging information. If you run the adb logcat command in Linux, you can see the following output: D/dalvikvm (745): GC_CONCURRENT freed 199 K, 53% free 3023 K/6343 K, external 0 K/0 K, paused 2 ms + 2 ms where D/dalvikvm indicates the debugging information output by dalvikvm, And the digits after the brackets represent the pid of the process where dalvikvm is located. GC_CONCURRENT indicates the cause of triggering garbage collection. GC_CONCURRENT is triggered when GC_MALLOC fails to be allocated. GC_EXPLICIT is triggered when the allocated object size exceeds kb, explicit call to garbage collection (System. gc) GC_EXTERNAL_ALLOC. If the external memory allocation fails, freed 199K is triggered, indicating that the garbage collection has released 53% K of memory, 3023 free 6343 K/K, of which 6343K indicates the total current memory, 3023K indicates available memory, and 53% indicates the proportion of available memory to total memory. External 0 K/0 K, indicating available external memory/total external memory paused 2 ms + 2 ms, the first time value indicates the markrootset time, the second time value indicates the time of the second mark. If the cause is not GC_CONCURRENT, this line is a single time value, indicating the time elapsed for garbage collection. 2. analysis (1) Although dalvikvm provides some debugging information, it still lacks some key information, such as the mark and sweep time. The memory allocation fails because of the memory allocation failure, there are also SoftReference, WeakReference and PhantomReference processing, and how many references are processed in each garbage collection. (2) Currently, all dalvik threads share a memory heap. In this way, the memory allocated must be mutually exclusive among threads. You can allocate a local thread storage heap for each memory, some small memory allocations can be directly allocated from the heap without mutex locks. (3) concurrentmark is introduced in the dalvik Virtual Machine. For multi-core CPUs, parrelmark can be implemented, that is, multiple threads can be used to run the mark stage simultaneously. These are the improvements that can be made to the memory management of dalvik virtual machines.

GC_FOR_MALLOCMeans 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.

GC_EXPLICITMeans 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.

There are a few others as well:

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

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

Typedefenum {
GC_FOR_MALLOC,
GC_CONCURRENT,
GC_EXPLICIT,
GC_EXTERNAL_ALLOC,
GC_HPROF_DUMP_HEAP
} GcReason;

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

The preceding Free memory is the memory used by java in the VM. external refers to the memory allocated by malloc in the Native class in JNI, such as Bitmap and some Cursor.
In Davilk, the memory allocated to a program varies with the model vendor. Most of the current memory is 32 MB, in the VM, the memory is divided into memory used by java and memory used by Native, which cannot be shared. That is to say, when your Native memory is used up, now Java has idle memory, and Native will apply again like VM instead of using java directly.
Example:
Free 3411 K/6663K and external 24870 K/26260 K
If a 2 m Bitmap needs to be created at this time, Native's existing memory is 26260-24870 = 1390 K <2048 k, so it will apply for memory from the Vm, although java's idle memory is
6663-3411 = 3252> 2048, but this part of memory Native is not available.
However, if you apply for 2 MB Native memory, the VM will tell you that it cannot be allocated because the used memory is close to the peak of 32 MB (26260 + 6663 = 32923 ), therefore, force close reports OOM. So now we need to check the usage of our native memory to avoid OOM.

 

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