Why Go has not yet implemented generational and compact GC

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

This article is translated from Google Forum (golang-nuts) Copyright @ the original.

Someone in the forum asked: Why Golang garbage collector does not implement generational and compact GC?

Ian Lance Taylor's reply:

This has been discussed in the past.

Ignoring details, the basic advantages of compact (compacting) GC are:

• Avoid fragmentation, as well;
• A simple and efficient bump splitter (bump allocator) is allowed.

However, modern memory allocation algorithms, like the Tcmalloc-based solution used by go runtime, are essentially free of fragmentation problems. The bump splitter is simple and effective for single-threaded programs in a multithreaded program that needs to be locked for go. In general, this might be more efficient to allocate memory using a set of per-thread caches. And at this point you have lost the advantage of the bump splitter. So I would assert that there are generally a lot of considerations that lead to today there is no real advantage to using a compressed memory allocator for a multithreaded application. I'm not saying there's a problem with the compression allocator, I just think it doesn't give any big advantage over non-compression. .

Now let's consider the generational GC. The key to generational GC relies on the assumption that most of the values allocated in a program will soon become useless, so the generational GC has the advantage of spending more time looking at recently allocated objects. Here Go is different from many garbage collection languages, because many objects are allocated directly on the program stack (stack). The go compiler uses escape analysis to find objects that are known at compile-time lifecycles and allocate them to stacks rather than garbage collected memory. So generally speaking, in Go, there is a large percentage of GC's that are not going to be used in a lot of different languages ( quickly-unused) value is not assigned to the primary location of GC memory. So the advantages of generational GC to Go are smaller than other languages.

More subtly, the hidden point implemented by most generations of GC is to reduce the time that garbage collection brings about program pauses. Only the youngest generation is seen during the pause and the pause time is short. However, go uses a concurrent garbage collector, and the program pause time in Go is independent of the size of the young generation or any generation. Go basically assumes that in a multithreaded program, by running GC on different cores in parallel, not to minimize GC time to pause causing the program to run longer, but overall to spend more total CPU time on the GC.

In summary, generational GC may still bring significant value to Go, which is to reduce the amount of work in parallel GC. This is a hypothesis that needs to be tested. Go the current GC work is actually closely following a related but different hypothesis: The Go program may prefer to allocate memory on request. Here's a description. It remains to be seen whether the situation is favourable in the ongoing process.