Garbage collection for Android virtual machines

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 on Google IO about the garbage collection part of the ART runtime, through his storytelling, We can see where art is improving in terms of garbage collection. To get to the point, let's look at the specific details below:

First look at how the GC works in Dalvik:

The process of Figure 1:GC

Figure 2: Suspend all threads for tagging, garbage collection to free up space

As you can see from Figure 1, when Dalvik starts garbage collection, the GC will go to find all the active objects, this time the entire program's thread will hang, and all the threads inside the virtual machine will hang at the same time (Figure 2) , so that the objects referenced are found in fewer stacks. It is important to note that this recycling action is performed concurrently with the application.

The reason for suspending all threads here is to make sure that all the programs are not making any changes, while the GC hides all the processed objects, and finally ensures that all objects that need to be reclaimed are flagged and the GC recovers all the threads and frees up space.

So in the Dalvik, hang all the threads this action priority is very high, in memory tense when the action will be frequently executed, which will cause the drop frame, interface lag phenomenon.

Figure 3: Why is the GC in D Alvik so lame?

as you can see from Figure 3, when you find that you need to allocate space for a larger object (the blue box), it is still sufficient to find the available space, but there is not such a large contiguous space for new objects to use, this time we have to do a GC reclamation (red squares)(Figure 3 ), freeing large and contiguous spaces for larger objects. This is one of the reasons why we are very prone to dropping frames and stalling when assigning a larger object. The solution could be to break up the larger objects into smaller objects and initialize them, but that doesn't solve the underlying problem.

We can also use a realistic comparison of the image of the residential parking phenomenon to explain: a longer car a (blue square) to find a parking space, found a lot of space, but the distance between the car and the car is larger, there is no suitable for a car stop position, At this time, you have to let the parking manager m (GC) to find out whether there is a non-local vehicle (Red Square) and recycling parking space for a car to use. (Here we can see that if the car stops tight enough, there is no need to bother the parking keeper)

From the above 3 graphs we can see that the GC problem in Dalvik is as follows:

1. Suspend all threads when GC

2. Large and continuous space tension

3. Memory fragmentation is critical

Let's look at how art solves these problems:

Figure 4 threads that do not need to suspend all programs in art

This can be compared to Figure 11, in ART, the GC will ask the program to tag its own stack when allocating space, the process is very short, do not need to suspend all program threads. This saves a significant portion of the time to find the active object. (resolve issue 1)

Figure 5 provides Los:large object space dedicated to bitmap use

As you can see from Figure 5, art has a separate Los for bitmap, which improves GC management efficiency and overall performance.

We also understand the parking phenomenon in the small district: the plot of a car dedicated to the area, so that the cart eliminates the time to find a parking space, but also reduce the number of Notification Manager m (GC). (Resolve Issue 2)

Fig. 6 Moving collector in art

In art there will also be a moving collector to compress the active objects (green squares), which makes the memory space more compact.

Small area parking phenomenon understanding: Parking Manager M will regularly move stop irregular car, make parking space more compact, maximize the use of effective space. (Resolve Issue 3)

After solving the three questions above, art has the following advantages:

1. Less Memory fragmentation

2. Shorter and fewer interrupts and blockages

3. Lower Memory utilization

Summary: Google has done a great job of optimizing GC in art, and from the demo data, memory allocation is 10 times times more efficient and the GC is 2-3 times more efficient. The main thing is to shorten the time of interruption and blocking by changing the timing of tagging, to solve the memory allocation and storage problem of large objects through Los, and to compress the memory by moving collector to make the memory space more compact, which can achieve a huge improvement of GC overall performance.

Garbage collection for Android virtual machines