Android 5.0 ART GC vs Android 4.x Dalvik GC

To study the memory management mechanism in the Android virtual machine, a preliminary investigation was made, and the following is a summary of the updates for GC in Android 5.0 ART for reference, from the web and the initial reading of the source code.

Google officially launched Android L at the I/O 2014 developers ' Conference on June 26, 2014, which is worth focusing on: The new Ui/ue design style and framework material designs, and the ui/of the Notification (Notification) column UE change can significantly improve the operating speed of the System Runtime Library Android Runtime (art). Project Volta dedicated to improving power consumption.

The 2nd of the art is the acronym for the Android Runtime, a substitute for Google's Dalvik virtual machine, which is used to replace the most maligned. In fact, art was launched early in the Android KitKat (version number 4.4), but it was still very imperfect, so it was put into the "developer Options" in the Setup program for the benefit of interested developers.

What is the magic of art? According to the relevant information, summarized as follows:
(1) using AOT (Ahead-of-time, precompiled) compiler technology, it can convert Java bytecode directly into the target machine's machine code.
(2) A more efficient and fine-grained garbage collection mechanism (GC).

The following is a brief introduction to the changes to the Android 5.0 ART GC:

(i) Memory allocator

Dalvik
Dlmalloc is a popular open source memory allocator that is used directly in the Android C language Library Bionic.

ART
Reference http://blog.tek-life.com/understanding-ros-memory-allocator-in-art-virtual-machine/ A allocator named Runs-of-slots-allocator (Rosalloc) was created. This allocator is characterized by a finer granularity of lock control when allocating memory. For example, there are different locks to protect different object allocations, or the thread's own stack is used when a thread allocates some small size objects, thereby eliminating the use of lock protection at all. At the same time, this kind of distributor is more suitable for multithreading implementation.
According to Google's own data, Rosalloc can achieve up to 10 times times the speed of ascension.

(ii) garbage collection algorithm

Dalvik
Dalvik garbage collection is divided into two stages.
In the first phase, Dalvik pauses all threads to analyze the usage of the heap.
In the second phase, Dalvik pauses all threads to clean the heap. This results in the application of "cotton" in performance.

ART
Art's improved garbage collection algorithm pauses threads only once. ART can do this because the application itself does some work of garbage collection. After the garbage collection starts, it is no longer two pauses, but a pause. In the traversal phase, the application does not need to be paused, and the garbage collection stop time is greatly shortened, because Google uses a new technology (Packard Pre-cleaning), doing a lot of things before the pause, easing the amount of downtime.

(iii) Support for large-object storage space
Art also introduces a special large object storage space (large object Space,los), which is separate from the heap space, but still resides in the application memory space. This particular design is designed to allow art to better manage larger objects, such as bitmap objects (bitmaps).
When heap space is heavily fragmented, larger objects can cause problems. For example, when assigning an object of this type, the number of times the garbage collector is started is much higher than other normal objects. With the support of this large object storage space, the number of calls raised by the garbage collector due to heap space fragmentation is greatly reduced, so that the garbage collector can make more reasonable memory allocations, thereby reducing the run-time overhead.

(iv) Moving GC policy
In order to solve the problem of memory fragmentation in heap space, art recently proposed a method of "moving GC". The purpose is to clean up the stack to reduce memory fragmentation. Because this work can cause the application to break for a long time, it must wait for the program to go back to the background. The core idea is that when the application runs in the background, the heap space of the program is merged into pieces.

(v) Diversity of GC scheduling strategies
After comparing the source code of Dalvik and art, it is found that the GC scheduling strategy in art has undergone great changes.
Specifically, it is divided into the following several aspects

(a) Type of GC trigger  
(b) GC  
(c) Diversity of garbage collection algorithms  

(a) GC trigger mode
(1) Dalvik
The main methods of GC triggering are gcformalloc; gcconcurrent; gcexplicit; Gcbeforeoom these four kinds.
(2) ART

Enum Gccause {//GC triggered by a failed allocation.  
  Thread doing allocation is blocked waiting for GC before//retrying allocation.  
  Kgccauseforalloc,//A background GC trying to ensure there be free memory ahead of allocations.  
  Kgccausebackground,//an explicit System.GC () call.  
  Kgccauseexplicit,//GC triggered for a native allocation.  
  Kgccausefornativealloc,//GC triggered for a collector transition. Kgccausecollectortransition,//Not a real GC cause, used when we disable moving GC (currently for Getprimitivearr  
  aycritical).  
  KGCCAUSEDISABLEMOVINGGC,//Not a real GC cause, used when we trim the heap.  
  Kgccausetrim,//GC triggered for background transition when both foreground and background collector CMS. Kgccausehomogeneousspacecompact,};

(b) Type of GC
(1) Dalvik
On a GC (concurrent, non-concurrency)
(2) ART
Three GC (concurrent, non-concurrency): Fast GC policy sticky GC; local GC policy partial GC; Global GC policy full GC.

Enum Gctype {  
  //placeholder for when no GC has been performed.  
  Kgctypenone,  
  //Sticky mark bits GC. Attempts to only free objects allocated since the last GC.  
  Kgctypesticky,  
  //Partial GC that marks the application heap but not the zygote.
  Kgctypepartial,  
  //Full GC-marks and frees in both the application and zygote heap. 
  Kgctypefull,  
  //number of different GC types.  
  Kgctypemax, 
};  

(c) Diversity of garbage collection algorithms
(1) Dalvik
Two kinds: serial mark-sweep algorithm, parallel mark-sweep algorithm
(2) ART

enum Collectortype {//No collector selected.  
Kcollectortypenone,//Non concurrent mark-sweep.  
Kcollectortypems,//Concurrent mark-sweep.  
KCOLLECTORTYPECMS,//semi-space/mark-sweep hybrid, enables compaction.  
Kcollectortypess,//A generational variant of kcollectortypess.  
KCOLLECTORTYPEGSS,//Mark compact colector.  
KCOLLECTORTYPEMC,//Heap trimming collector, doesn ' t do any actual collecting.  
Kcollectortypeheaptrim,//A (mostly) concurrent copying collector. KCOLLECTORTYPECC,//A homogeneous space compaction collector used in background transition//when both foreground  
D background Collector are CMS.  Kcollectortypehomogeneousspacecompact,}; 

It can be seen that, in addition to the mark-clear algorithm, the Semi-space-based copy algorithm is also implemented, in which the implementation of GSS (half space copy algorithm) has great research.

The above is only preliminary understanding, many places have to be studied in detail before they can be identified.

Reference:
"1" http://www.cnblogs.com/jinkeep/p/3818180.html "original" "Android" revealing ART details----garbage collection
"2" Https://www.infinum.co/the-capsized-eight/articles/art-vs-dalvik-introducing-the-new-android-runtime-in-kit-kat
"3" http://www.lingcc.com/2014/07/16/12599/the Android Art Runtime library at close range

"4" Http://blog.tek-life.com/understanding-garbage-collector-in-art-of-android/

Original address: http://hello2mao.github.io/2015/12/11/ART_GC_VS_Dalvik_GC.html