This is a creation in Article, where the information may have evolved or changed.
Although go 1.5 has just been released, it is still relatively new, but the go team is already working on improving its new low latency concurrent garbage collector, and hopefully go is better suited for new application areas. Google engineer Austin Clements and Rick Hudson said.
Go 1.5 replaces the original STW (Stop-the-world) GC with the new garbage collector, which solves the latency problem. When the load is heavy, the active time of the new GC can be controlled below 10ms per 50ms, thus allowing the go program to run faster in general. In more extreme cases, the pause can drop from 300ms to 4ms.
The goal of Go 1.6 is to further stabilize the GC and to make improvements in the following areas:
- State Coordination: The main bottleneck of the Go 1.5 gc is inherited from Go 1.4, derived from its centralized GC coordinator (Coordinator), a separate goroutine that assigns the work to the worker goroutine to complete. One solution is to use a centralized state machine instead of a central coordinator. This modification has an additional benefit, making it possible to redesign Markcompletion barrieras it becomes very messy and poorly performing.
- Credit System: Go 1.5 uses a credit system in two different places: one is to ensure that the sweep (sweeping) is done between a GC cycle and the next trigger heap operation (the next heap trigger), and one is to ensure that the scan (scanning) is triggered in the heap operation ( An heap trigger ) and then implement the heap processing target. One of the recommended ways to improve the credit system is to keep its operations in the black phase to avoid the unfinished allocation operation entering the next GC cycle.
- Mark termination: According to Clements and Hudson, in Go 1.5, the mark end stage is the head of the pause time. The goal here is to try and make sure that most applications can run at a threshold of 10ms pauses, which is what go 1.5 has done in many cases. It is expected that the complexity of the modifications will be low or moderate, such as moving the finalizer scan from the end of the tag to the concurrent scan, which should save 1ms for every 1GB size heap, and remove a high-cost counting cycle, which takes up the other half of the marking phase for larger heaps.
- Sweeper and Scavenger: Some programs spend a lot of time on the sweeper, putting some effort into it, and there should be performance improvements. A very radical solution is to completely remove the sweeper. There is also a less aggressive scenario where you can release larger objects as early as possible at the end of the GC phase, and support scavenger on all systems, regardless of how large the physical page is.
above is just an overview of the improvements made to the plan, and you can read the original document for a full understanding. The documentation also links to GitHub issues, which document the rationale behind each change and the suggested scenarios.
