Go gc:prioritizing Low latency and simplicity

This is a creation in Article, where the information may have evolved or changed.

Https://blog.golang.org/go15gc

Before you start, let's take a look at a discussion about the garbage collection of Go
http://www.zhihu.com/question/21615032

The Setup

Go is building a future-oriented modern garbage collector (garbage collector, GC): A long-term GC that not only adapts to the scale of today's software development, but also supports the software and hardware capabilities of the next decade. The current full-stop (Stop-the-world) GC has hindered the wider use of security languages such as go, and in the future, there may be no full-stop GC foothold.
Go 1.5, as a glimpse for the future, reached the target of the 10 millisecond GC delay we set a year ago. We showed some exciting data at the a talk at Gophercon. Among other things, the delay improvements received widespread attention; Robin Verlangen's blog billions of requests per day meet Go 1.5 Let us see the consumer's feedback on the new GC. At the same time we are particularly satisfied with Alan Shreve's Productoin server graphs in its "Oh, 85% delay reduction!!!" "Of praise.

Today 16G of memory only requires $100, and CPUs have more and more cores, more and more hyper-threading. Ten years from now the hardware may become antique furnishings, and software built with go will need to scale out to accommodate more demands and challenges. With the ability to improve productivity on that hardware basis, Go's garbage collection design takes into account the first delay and easy-to-manipulate store. Go 1.5 is the first step in that direction, and this step will always affect the development of go and related applications. This blog will systematically introduce our efforts in the Go 1.5 garbage collector.

The embellishment

To build a future-oriented GC, we looked at an algorithm that emerged decades ago. The new GC for Go is a concurrency (concurrent), Tri-color (tri-color), Tag-Clear (Mark-sweep) collector, derived from the idea of Dijkstra in 1978. We believe that this algorithm can adapt to the needs of modern hardware and low-latency software systems because of the maximum cost-level garbage collector.

In a tri-color collector, each object has one of three colors (white, gray, and black). We look at the objects in a connected graph. At the beginning of each GC, all objects are white. The GC accesses those root node objects, including global objects, objects in the stack, and marks them as gray. The GC then selects a gray object, changes it to black, and then accesses other objects along the pointer to other objects. When it accesses a white object, it marks the white object as gray. The process repeats until there are no more gray objects. At this point, the remaining white objects are unreachable and should also be recycled. (For more information on tri-color mark removal, see Wikipedia).

All of this is happening concurrently, and we can treat each operation point as a mutation point and change the access pointer as the collector runs. Therefore, the mutation point needs to maintain an invariant during the operation-No black object pointing to the white object, preventing the GC from losing track of the accessed elements in the heap. Maintaining this invariant is achieved by a write barrier (itself a small piece of the program executed by the mutation point in the process of modifying the pointer). The go write barrier dims all the white nodes that are now available, ensuring that the GC finally has access to all the nodes it can access.

It is a complex and delicate task to judge whether the traverse is completed without blocking the mutation point. To simplify this process, Go 1.5 takes as much concurrency as possible and then briefly stops to check all potential gray nodes. Finding the balance between the full stop time and the GC workload between the desserts is a result that can be reused by Go 1.6.

The difficulty, of course, lies in the details of the implementation. Like when does the GC start traversing? How do I determine the start traversal? How can the GC interact with the GO scheduler? How do we pause a stack that runs a long enough mutation process to check it? How do we represent the lime black three states so that we can efficiently find the gray object? How do I find the root node for traversal? How do I find the object reference pointer? How do I minimize the fragmentation of memory? How do I optimize cache performance? Heap How big is this setting? All these, some lies in the allocation, some lies in the search, some lies in the dispatch, more lies in the performance. The discussion of these more underlying topics is beyond the scope of this article.

From the top level, one solution to the performance problem is to increase the GC's gripper, and the other is to improve the performance of each gripper. The former programmer can adjust the gripper in their application. The downside is adding one or two new grippers every few years, and each year you're stuck in the repetitive work of GC gripper deployment. Go is not ready to do that. Instead, we only provide a GC gripper, called GOGC. This value controls the size of your stack, relative to the size of the object you can currently reach. The default value of 100 indicates that the current heap space is 100% larger than the size of the object that could be touched at the time of the last collection. 200 means that the current heap space is 200% (3 times times the size) larger than the last reclaimed object. If you want to reduce the time spent on GC, add GOGC. If you want to use more GC time to reduce memory, then reduce GOGC.

More importantly, with the development of the next generation of hardware, memory will quickly double, simply increase the size of the GOGC will halve the GC cycle. On the other hand, since GOGC represents the relative value of the number of objects currently available, there is no need for you to readjust this parameter to change the number of objects. The app adjusts the scale automatically. Moreover, without increasing the burden of support for various grippers, the runtime team can focus on the main work of improving the operational timeliness based on application feedback.

The punchline

The Go 1.5 GC opens up a full-stop GC that is no longer a safe and reliable language barrier. It shows that with the development of hardware, software applications can move effortlessly to new hardware, and GC does not become a hindrance. The next ten years and beyond will benefit from this. Read more about the GC for Go 1.5 and how we can solve the delay problem in Go gc:latency problem Solved presentation or handouts