A reference tracking algorithm of garbage collection algorithm

In this blog, the reference counting algorithm for garbage collection algorithms, we talk about the drawbacks of the reference counting algorithm: Problems that can cause circular references. The reference tracking algorithm in this article is the customer service of this flaw.

In the reference counting algorithm, for each referenced object, we have an extra field that specifically counts the number of times the object is referenced, and when the number is 0 o'clock, it is considered garbage. So how do we tell if this object is garbage in the reference tracking algorithm? The answer is: The object is up to the graph.

A Object up to graph

The implication is that all objects are first marked as garbage and treated as roots, starting from the root, concatenating all the objects being used, up to the end, the objects that are not concatenated are "unreachable", which is considered garbage, and "accessible" objects are considered useful and survive the garbage collection process.

Static voidMain (string[] args) {   varObj1 =New Object();//Step1DoSomething ();//Step2   varObj3 = obj1;//Step3}//Step4Static voiddosomething () {varObj2 =New Object();}

Let's take a look at the following piece of code to draw an object to the graph according to the meaning of the graph. The overall invocation relationship is as follows:

We assume that, after running to Step3, a garbage collection was made before the STEP4 was run.

First: Find out all the root objects and flag them as "garbage", this is done by setting the synchronization block index to zero, which we call the "mark" phase.

After running to Step3, Obj1 and Obj2 and Obj3 are the 3 roots here, where the root obj2 has been popped out of the stack, so there are only two root objects obj1 and obj3 in the stack:

Because the root Obj1 References Object Object 1, one of the synchronization block indexes of Object 1 is set to 1 to mark it not garbage, and then to check the object reference of the root obj3, and to find that it also refers to object 1 when it is just about to flag one of its synchronized index blocks. found that object 1 has already been marked, it is not re-tagged. this avoids the cycle of loops that result from circular references.

It is important to note that object A is also tagged when it is marked with Object Object 1 o'clock and finds that it references other objects (assuming a).

The tagging process continues, checking all the roots in turn. When the tag is complete, the objects in the heap are either marked or unmarked, forming an object to reach the graph, the objects in the graph are not garbage, and unreachable objects are considered garbage. Once you know what is rubbish, the next step is the compression phase.

Two Compression phase

The primary task of the compression phase is to compress the surviving objects into a continuous process, because, depending on the locality of the application, it is more advantageous to reduce the assembly, free up memory, solve the heap's spatial fragmentation problem, and improve the cache hit ratio. In terms of, we just want to compress the Acef object into a continuous, it is very simple, we just need to move the C object behind a, E object moved to the C, and so on, you can make these memory objects into a continuous.

After this step, in fact, two problems need to be solved, the first is the C memory compression, its actual position in the heap changes, the root reference c is the original location, if left to go, will access the old memory address and cause memory corruption. Therefore, the address of the reference C in the root is subtracted from the number of bytes offset in the compression, so that each root is referred to the original C, except that the object is transformed in memory.

The second problem to be solved is that the newobjptr pointer is also calculated to offset the number of bytes assigned to the next object in the heap, so that the memory allocated by the new object is contiguous with the original heap memory.

The following is the managed heap after garbage collection:

After garbage collection, the memory is impossible to leak, because objects can be reached in the graph of unreachable objects, will be recycled, and second, because access to unreachable objects can cause memory corruption, because now can only reference reachable objects, unreachable objects are not referenced.

Reference documents

"CLR via C #" (4th edition)

A reference tracking algorithm of garbage collection algorithm