Android Studio--Read garbage collection messages

Sometimes when a garbage collection event occurs, they're printed to logcat.

For more detail about your app's memory, use the Memory Profiler.

Dalvik log messages

In Dalvik (but not ART), every GC prints the following information to logcat:

D/dalvikvm(PID): GC_Reason Amount_freed, Heap_stats, External_memory_stats, Pause_time

Example:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

GC Reason

What triggered the GC and what kind of collection it is. Reasons that might appear include:

GC_CONCURRENT

A concurrent GC that frees up memory as your heap begins to fill up.

GC_FOR_MALLOC

A GC was caused because your app attempted to allocate memory when your heap was already full, so the system had to stop your app and reclaim memory.

GC_HPROF_DUMP_HEAP

A GC that occurs when you request to create an HPROF file to analyze your heap.

GC_EXPLICIT

An explicit GC, such as when you call  gc() (which you should avoid calling and instead trust the GC to run when needed).

GC_EXTERNAL_ALLOC

This happens only on API level 10 and lower (newer versions allocate everything in the Dalvik heap). A GC for externally allocated memory (such as the pixel data stored in native memory or NIO byte buffers).

Amount freed

The amount of memory reclaimed from this GC.

Heap stats

Percentage free of the heap and (number of live objects)/(total heap size).

External memory stats

Externally allocated memory on API level 10 and lower (amount of allocated memory) / (limit at which collection will occur).

Pause time

Larger heaps will have larger pause times. Concurrent pause times show two pauses: one at the beginning of the collection and another near the end.

While these log messages accumulate, look out for increases in the heap stats (the 3571K/9991K value in the above example). If this value continues to increase, you might have a memory leak.

ART log messages

Unlike Dalvik, ART doesn't log messages for GCs that were not explicitly requested. GCs are only printed when they are they are deemed slow. More precisely, if the GC pause exceeds 5ms or the GC duration exceeds 100ms. If the app is not in a pause perceptible state (such as when the app is in the background, where the user cannot preceive a GC pause), then none of its GCs are deemed slow. Explicit GCs are always logged.

ART includes the following information in its garbage collection log messages:

I/art: GC_Reason GC_Name Objects_freed(Size_freed) AllocSpace Objects,
    Large_objects_freed(Large_object_size_freed) Heap_stats LOS objects, Pause_time(s)

Example:

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects,
    21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

GC Reason

What triggered the GC and what kind of collection it is. Reasons that might appear include:

Concurrent

A concurrent GC that does not suspend app threads. This GC runs in a background thread and does not prevent allocations.

Alloc

The GC was initiated because your app attempted to allocate memory when your heap was already full. In this case, the garbage collection occurred in the allocating thread.

Explicit

The garbage collection was explicitly requested by an app, for example, by calling  gc() or  gc(). Like Dalvik, in ART the best practice is that you trust the GC and avoid requesting explicit GCs, if possible. Explicit GCs are discouraged because they block the allocating thread and unnecessarily waste CPU cycles. Explicit GCs could also cause jank (stuttering, juddering, or halting in the app) if they cause other threads to get preempted.

NativeAlloc

The collection was caused by native memory pressure from native allocations such as Bitmaps or RenderScript allocation objects.

CollectorTransition

The collection was caused by a heap transition; this is caused by changing the GC strategy at run time (such as when the app changes between pause perceptible states). Collector transitions consist of copying all the objects from a free-list backed space to a bump pointer space (or visa versa).

This occurs only on low RAM device prior to Android 8.0 when an app changes process states from a pause perceptible state (such as when the app is in the foreground, where the user can preceive a GC pause) to a non pause perceptible state (or visa versa).

HomogeneousSpaceCompact

Homogeneous space compaction is free-list space to free-list space compaction which usually occurs when an app is moved to a pause imperceptible process state. The main reasons for doing this are reducing RAM usage and defragmenting the heap.

DisableMovingGc

This is not a real GC reason, but a note that collection was blocked due to use of GetPrimitiveArrayCritical. while concurrent heap compaction is occurring. In general, the use of GetPrimitiveArrayCritical is strongly discouraged due to its restrictions on moving collectors.

HeapTrim

This is not a GC reason, but a note that collection was blocked until a heap trim finished.

GC Name

ART has various different GCs which can get run.

Concurrent mark sweep (CMS)

A whole heap collector which frees collects all spaces other than the image space.

Concurrent partial mark sweep

A mostly whole heap collector which collects all spaces other than the image and zygote spaces.

Concurrent sticky mark sweep

A generational collector which can only free objects allocated since the last GC. This garbage collection is run more often than a full or partial mark sweep since it is faster and has lower pauses.

Marksweep + semispace

A non concurrent, copying GC used for heap transitions as well as homogeneous space compaction (to defragement the heap).

Objects freed

The number of objects which were reclaimed from this GC from the non large object space.

Size freed

The number of bytes which were reclaimed from this GC from the non large object space.

Large objects freed

The number of object in the large object space which were reclaimed from this garbage collection.

Large object size freed

The number of bytes in the large object space which were reclaimed from this garbage collection.

Heap stats

Percentage free and (number of live objects)/(total heap size).

Pause times

In general pause times are proportional to the number of object references which were modified while the GC was running. Currently, the ART CMS GCs only has one pause, near the end of the GC. The moving GCs have a long pause which lasts for the majority of the GC duration.

If you are seeing a large amount of GCs in logcat, look for increases in the heap stats (the 25MB/38MB value in the above example). If this value continues to increase and doesn't ever seem to get smaller, you could have a memory leak. Alternatively, if you are seeing GC which are for the reason "Alloc", then you are already operating near your heap capacity and can expect OOM exceptions in the near future.

From:https://developer.android.com/studio/debug/am-logcat.html