Shulou(Shulou.com)05/31 Report--

What is the principle of golang garbage collection? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Concurrent garbage collection

The fundamental pursuit of golang language design is high concurrency and low latency, so golang garbage collection is constantly optimized. Golang garbage collection is concurrent garbage collection design, business operation and collector operation concurrency. The original purpose of this design is to reduce the garbage collection pause time.

As an example, if you want to safely implement garbage collection, the simple thing is to stop all business operations when collecting garbage. The term is STW (stop the world). The following terms are used:

Assignment: this is the program's business code collector: garbage collector STW secure collection

The following diagram shows an evolution of this simple example:

Gray indicates one garbage collection operation, black indicates the next time.

In the picture, we see:

In a single-processor scenario, the code of the assignment and the collector runs alternately, and the recovery time of the collector is the time when the assignment is paused; in the case of multiple processors, multiple assignment threads execute in parallel, but each time the collector is collected, multiple assigns are still suspended; the third is to let multiple processors execute the tasks of the collector in parallel to reduce the pause.

This is an obvious implementation and optimization evolution, in fact, we can go a step further, we can split a complete recycling task into small granularity, into incremental recycling, so that a single pause time is even less.

Concurrent garbage collection

Golang is obviously not this (, used to be), golang has to make the assignment and recycler concurrent, there can be no obvious pause. Golang's current garbage collection features:

Completely eliminates the obvious STW (except when garbage collection is turned on) the collector flag, the collection process is completely concurrent with the assignment, but note that for a single stack, it is a pending scan, which is called on-the-fly collection, and is incremental.

Before the recovery of golang has no mixing barrier, it always inserts the write barrier. Because the stack assignment has no hook, there is STW. After the mixed write barrier, there is no STW.

Here is a point to understand: STW is a global valuator hang, we have always said that golang eliminated STW said that there is no global hang, but there has always been a local valuator hang, including now.

Insert write barrier pseudo code

The Write operation changes the value of a particular memory. The change operation causes memory storage, which requires three parameters: the pointer to the source, the index of the domain to be modified, and the value to be stored. The write assignment operation is represented by pseudo code:

Write (src, I, val): src [I] null Collector Operation 1: Scan Y Collector Operation 2: recycle Z (this is a problem)

Only when these two conditions occur at the same time will the object be mistakenly recycled. Then we look back at the implementation of the write barrier and find that the write barrier fundamentally destroys the emergence of the first condition.

How does the writing barrier solve the problem?

A schematic diagram with a barrier:

Inserting the write barrier is as simple as that. As long as you ensure that there is no condition that a black object points to a white object at all times, the correctness of recycling can be guaranteed. But then again, this barrier is needed to match the concurrency of the assignment collector, so if you allow direct STW to execute the collector logic, it doesn't need to be so complicated, of course, the performance of the assignment will not be good.

Although inserting a write barrier can solve the problem, golang does not capture the assignment of objects on the stack (no write barrier is generated), naturally due to performance attrition and implementation complexity. This opens an exception where some black stack objects point to white objects that the recycler cannot perceive. Golang's solution is to STW and then rescan a stack. This will naturally lead to the whole process's assignee stutter, so the later golang is to use the mixed write barrier to solve this problem.

After reading the above, have you mastered the principle of golang garbage collection? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.