[Original] [Android] reveals ART details

Background

Dalvik: http://zh.wikipedia.org/wiki/Dalvik%E8%99%9A%E6%8B%9F%E6%9C%BA

ART: http://source.android.com/devices/tech/dalvik/art.html

Body

Ian Rogers described The Garbage Collection section of The ART runtime on Google IO 2014. Through his introduction, we can see what improvements ART has made in Garbage Collection. Let's take a look at the details below:

First, let's take a look at how GC works in Dalvik:

Figure 1 GC Process

 

Figure 2: suspend all threads for marking and recycle to release space

 

As shown in figure 1, when Dalvik starts garbage collection, GC searches for all active objects, and the thread of the entire program suspends, all threads in the virtual machine will also be suspended (Figure 2) at the same time, so as to locate the referenced object in a few stacks. Note that this recycle action is executed simultaneously with the application.

The reason for suspending all threads is to ensure that no changes are made to all programs. At the same time, GC hides all processed objects and, finally, marks all objects to be recycled, GC restores all threads and releases space.

Therefore, in Dalvik, the priority of the action to suspend all threads is very high. When the memory is tight, this action will be executed frequently, resulting in Frame loss and interface freezing.

Figure 3: Why is the GC in Dalvik so frustrated?

 

As shown in figure 3, when we find that we need to allocate space to a large object (blue square), we find that the available space is sufficient, but there is not such a large continuous space for new objects. At this time, we have to perform a GC recycle (red box) (Figure 3) to create a large and continuous space for large objects. This is one of the reasons why frame loss and frame freezing are very likely to occur when we allocate a large object. The solution is to break down a large object into several smaller objects and initialize them, but this does not solve the fundamental problem.

We can also use A relatively real-world community parking phenomenon to explain: A long car A (blue square) to find A parking space, found that there are many empty locations, however, the distance between the vehicle and the vehicle is large, and there is no suitable location for A's parking. At this time, the parking space administrator M (GC) has) check whether there are non-residential vehicles (RED block) and reclaim the parking space for A car. (Here we can find that if the car is parked tightly enough, there is no need to bother the parking space administrator)

From the above three figures, we can see the GC problem in Dalvik as follows:

1. All threads are suspended during GC.

2. Large and continuous space shortage

3. Serious memory fragmentation

Let's take a look at how ART solves these problems:

Figure 4 threads of all programs do not need to be suspended in ART

 

As shown in figure 1, GC in ART requires the program to mark its stack when allocating space. This process is very short and does not need to suspend all program threads. this saves a lot of time searching for activity objects. (Problem Solving 1)

 

Figure 5 provides the LOS: large object space for Bitmap

 

As shown in figure 5, ART has an independent LOS for Bitmap, which improves GC management efficiency and overall performance.

We can also understand the parking phenomenon in the community: the Community draws a dedicated area for a large car, saving the time for the car to find a parking space and reducing the number of times to notify the Administrator M (GC. (Problem Solving 2)

Figure 6 moving collector in ART

 

In ART, there will also be a moving collector to compress the active objects (green blocks), making the memory space more compact.

From the Community parking phenomenon understanding: the parking space administrator M will regularly move the car with irregular parking, making the parking space more compact and maximizing the use of effective space. (Problem Solving 3)

After solving the above three problems, ART has the following advantages:

1. Less memory fragments

2. Shorter and fewer interruptions and blocking

3. Lower memory usage

 

Conclusion: Google has greatly optimized GC in ART. From the demo data, the memory allocation efficiency is improved by 10 times, and GC efficiency is improved by 2-3 times. The main reason is to shorten the interruption and blocking time by marking the change of the time. The LOS is used to solve the memory allocation and storage problems of large objects. The moving collector is used to compress the memory and make the memory space more compact, this greatly improves the overall GC performance.

 

PS:

If you like this article, please click the recommendation in the lower right corner. You are welcome to repost it!