Introduction to the garbage payback period algorithm and the payback period Algorithm

Introduction to the garbage payback period algorithm and the payback period Algorithm

The garbage collector checks whether there are objects in the managed heap that are no longer used by applications. If so, the memory they use can be recycled (if there is still no available memory in the heap after a garbage collection, the new operator will throw an OutOfMemoryException ). How does the Garbage Collector know that an object is being used by an application? This is complicated.

Each application contains a group of roots. Each root is a storage location, which contains a pointer to a reference type object. The pointer either references an object in the managed heap or is null. For example, any static field defined in the type is considered as a root. In addition, parameters and local variables of any method are considered as a root. Only variables of the reference type can be considered root; variables of the value type are never considered root.

When the garbage payback period starts, it assumes that all objects in the heap are junk. In other words, it assumes that the thread stack does not reference the variables of objects in the heap, and no CPU registers reference objects in the heap, no static fields reference objects in the heap. The first stage of the garbage collection period is the so-called Marking stage. Check all the roots of the garbage collection period along the thread stack. If a root references an object, mark it on the "synchronized block index field" of the object. For example, the garbage collector finds a local variable pointing to an object in the heap. A heap is displayed, which contains several allocated objects. The root of the application directly references objects A, C, D, and F.

All these objects are marked. When marking Object D, the garbage collection period finds that this object contains a field that references object H, and the object H is also marked. In this way, the garbage collection period traverses all reachable objects in recursion.

 

After the root and Its referenced fields are marked, the garbage collector checks the next root and continues to mark the object. If the garbage collection period is used to mark an object previously marked. It will stop following this path. This behavior has two purposes. First, the garbage collection period does not traverse a group of objects, so the performance can be improved. Second, if a circular linked list of objects exists, you can avoid infinite loops.

After all the roots are checked, the heap will contain a group of marked and unmarked objects. Marked objects are accessible through applications, but unmarked objects are not reachable. Inaccessible objects are considered as spam and their occupied memory can be recycled, now the second stage of garbage collection is compressed. In this phase, the garbage collector traverses the heap linearly to find continuous memory blocks of unlabeled objects. If the detected memory blocks are small, the garbage collection cycle will ignore them. If the detected memory blocks are large, the garbage collector will move non-junk objects here to compress the stack.

 

Naturally, after moving an object in memory, containing pointer variables pointing to these objects will become invalid. Therefore, the garbage collection period begins to reproduce the root of the application and modify them to point to the address of the new memory. In addition, if the fields in the object point to the fields of another moved object, the garbage collection period is also responsible for correcting the values of these fields. After the heap memory is compressed, The NextObjPtr pointer of the managed heap points to the next position after the last non-garbage collection, which is the managed heap after the garbage collection.

 

 

As you can see, the garbage collection period can cause significant performance losses, which is the main disadvantage of using managed heaps. However, it should be noted that the garbage collection payback period is only when the 0 generation is full. Previously, managed heap had far higher performance than C runtime. Finally, CLR provides some special Optimization Measures to Improve the garbage collection performance. (The concept of generation will be discussed later)

As a programmer, we have drawn two important understandings from the previous discussions. First, you do not have to write code to manage the lifetime of the objects used by the application. Second, the bug described in the previous chapter will no longer exist. First, it is impossible to expose objects. Any object that is referenced by the application without a root will be reclaimed at a certain time point in the garbage collection period. Therefore, the application cannot cause memory leakage, in addition, applications cannot access released objects. Second, it is impossible to access a released object. This is because if the object is reachable, it will not be released; if it is inaccessible, the application will not be able to access it. In addition, because the Garbage Collector causes memory compression, the hosted object cannot cause fragmentation of the virtual space address of the hosting heap process. If the code is not managed, the address space fragmentation may be very serious. However, this problem does not occur when using managed heaps. In addition, when using large objects, managed heaps may still be fragmented.