C + + Memory Management Change (2): The most compact garbage collector

Overview

One of the most criticized C + + is that there is not a single memory garbage collector (exactly, no standard garbage collector). The main point of this article is to implement one of the most compact, feature-constrained garbage collector in C/s + +. The main characteristics that this garbage collector distinguishes from other garbage collector are:

1. Compact but practical. The entire garbage collector code line is around 100 lines (excluding blank lines), rather compact. Relatively speaking, its function is also subject to a certain limit. But it is very useful in a number of key situations. The garbage collector, as a primary goal of utility, has become an important tool for me and some colleagues around me to program.

2. High performance. What distinguishes it from other garbage collector is that this pocket-sized garbage collector, instead of causing performance degradation, improves the program's time performance (the speed at which it is allocated) and space performance (which takes up less memory space than normal malloc/new). And this is a practical important indicator.

This algorithm is not complicated. The technical things, many point out that there is nothing, perhaps the important significance is its initiative. In fact, the pool component provided by Boost[1 is also trying to provide an automatic memory recovery capability similar to functionality. But implementation is relatively complex and inefficient (based on classic Mempool technology [2]).

Now, you may be anxious to see what this garbage collector looks like. Gossip less, then let us start a step-by-step to solve the mystery.

Ideas

The key to understanding the garbage collector is to understand its goal: to provide an automatic memory recovery capability for a complex local process (algorithm).

The so-called local process (algorithm), which is the complexity of those algorithms, but in the process of running the period of time is relatively short period [3]. For example: Search engine, read disk/save process, display (drawing) process and so on. Usually these processes may require a lot of memory, and the memory allocation operation has a lot of entry points (that is, a lot of places to call new), if each call to the new to consider where to delete the waste of our valuable brain, so we can not concentrate on the design of the algorithm itself. Perhaps it is in this case that C + + programmers are particularly envious of the languages that have garbage collector. Relatively speaking, if the algorithm complexity is not high, our programmers are fully capable of controlling the new/delete matching relationship. And the feeling that "everything is in my hands" gives us a sense of security [4] and contentment.

Therefore, the center of gravity of this garbage collector is not to provide a theoretically full-featured memory automatic recovery mechanism. It is only for the high complexity of local processes (algorithms), to provide them with the most effective memory management tools. From the beginning of a local process, you just have to apply, use the memory, wait until the entire algorithm is complete, the process of the application of most of the memory (need to be retained as the algorithm result of the exception), whether it is in the algorithm that step of the application, all at this end point by the garbage collector automatically destroyed. Let's draw a schematic:

Figure 1