Garbage collection log information in Android

cause

Gc_concurrentfreed 178K, 41% free 3673k/6151k, external 0k/0k, paused 2ms+2ms
Gc_explicitfreed 6K, 41% free 3667k/6151k, external 0k/0k, paused 29ms

The red color is the part that causes the garbage collection to trigger. There are five types of garbage collection triggering reasons in Android.

• Gc_concurrent is triggered when heap memory grows to a certain extent. This triggers the ability to reclaim unused objects in the heap in a timely manner, freeing up space for new object requests, and avoiding unnecessarily increasing heap memory operations.
• Gc_explicit is triggered when a program calls the System.GC () method. This method should avoid being called in the program. Because the JVM has enough power to control garbage collection.
• Gc_external_malloc when bitmap and NiO Direct Bytebuffer objects are allocated external storage (machine memory, non-Dalvik heap memory) is triggered. This log exists only before 2.3, starting with the 2.3 system, the garbage collection is adjusted, and the preceding objects are stored in the Dalivik heap memory. So after the 2.3 system, you will never see this information again.
• Gc_for_malloc triggers when the heap memory is full and the system needs more memory. This log appears to mean that the JVM will suspend your program for garbage collection operations.
• Gc_hprof_dump_heap is triggered when a memory analysis file HPROF is created.

Results

Gc_concurrentfreed 178K, 41% free 3673k/6151k, external 0k/0k, paused 2ms+2ms
Gc_explicitfreed 6K, 41% free 3667k/6151k, external 0k/0k, paused 29ms

This part of the data tells us how much space the JVM has freed up for garbage collection.

Heap Memory Data

Gc_concurrent Freed 178k,41% free 3673k/6151k, external 0k/0k, paused 2ms+2ms
Gc_explicit Freed 6k,41% free 3667k/6151k, external 0k/0k, paused 29ms

This section tells us the proportion of available memory in heap memory, the total space of the currently active objects, and the total size of the current heap. So the data here is 41% of the heap memory available, has used 3673K, the total heap memory size is 6151K.

Externally stored data

Gc_external_alloc freed 1125K, 47% free 6310k/11847k,external 1051k/1103k, paused 46ms
Gc_external_alloc freed 295K, 47% free 6335k/11847k,external 1613k/1651k, paused 41ms

This part of the data tells us the data of the external storage (located in the machine memory) object. Before 2.3, the bitmap object was stored in machine memory. So in the first piece of data we can see that 1051K is used and the external storage is 1103K.

The above two lines of data 100 milliseconds apart, we can see the first data indicates that the external storage is almost full, because the gc_external_alloc is triggered, the external storage space expanded to 1651K.

garbage Collection Pause time

Gc_concurrent freed 178K, 41% free 3673k/6151k, external 0k/0k,paused 2ms+2ms
Gc_explicit freed 6K, 41% free 3667k/6151k, external 0k/0k,paused 29ms

This part of the data indicates when garbage collection is consumed. When gc_concurrent is recycled, you will find two pause times. One is the pause time at the start of the recycle, and the other at the end of the recycle period. Gc_concurrent was introduced from 2.3, and its pause time was much smaller than the garbage collection mechanism, which was completely paused by the previous program. Generally less than 5 milliseconds. Because the vast majority of gc_concurrent operations are performed in a separate thread.

Garbage collection log information in Android