Memory debugging things d/dalvikvm (809): gc_concurrent freed

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

Among them, D/dalvikvm indicates the debugging information output by dalvikvm, And the digits behind the brackets represent the PID of the process where dalvikvm is located.

Gc_concurrent indicates the cause of triggering garbage collection. There are several reasons:

• Gc_malloc triggered when memory allocation fails

 

• Gc_concurrent, triggered when the allocated object size exceeds 384k

 

• Gc_explicit, explicit call to garbage collection (system. gc)

 

• Gc_external_alloc triggered when external memory allocation fails

Freed 199k indicates that the garbage collection has released 199k of memory,

53% free 3023 K/6343 K, of which 6343k indicates the current total memory, 3023k indicates available memory, 53% indicates the proportion of available memory to the 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 time of the markrootset, and 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 Mark and sweep time,

Memory Allocation fails because of the size of the allocated memory, as well as the processing of softreference, weakreference and phantomreference, and the number of references processed by 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.