1. What is Garbage?
Each application has a set of root users. The root can be used to indicate the storage location. These locations point to objects in the managed heap or null objects, called the active root, and form an active root list. The JIT compiler and CLR maintain the active root list, which can be accessed by the garbage collector algorithm. In this way, spam is defined as a heap object that cannot be accessed from the active root list.
2. How is garbage collected?
When the Garbage Collector starts running, it assumes that all objects in the heap are junk. In other words, it assumes that no root in the application points to objects in the heap. GC starts to traverse the root list and creates an object graph that can be reached from the root. For example, GC may locate global variables pointing to objects in the heap and recursively traverse all reachable objects. When this part of the object graph is traversed, GC checks the next root and traverses the objects.
Garbage Collector traversal: 1. GC only compiles a group of objects once to improve performance. 2. If an object contains a circular linked list, infinite loops can be avoided.
3. Performance of the Garbage Collector
The performance of garbage collection depends on: 1. The size of the managed heap; 2. the garbage size; 3. Whether the finalize () method is defined for objects in the managed heap. (Calling the finalize method for recyclable objects will slow down the garbage collection speed)
Another bottleneck is the large objects in the heap. If the C-disk structure is the most tree retained in the memory, when another program continuously references this tree during execution, this tree will remain in the heap and will never be recycled as garbage. The best way to deal with such a large object is garbage collection and application access at the same time. This method is implemented through weak reference. This mechanism is based on the choice of access and garbage collection opportunities! On the one hand, if the object only has weak references and GC is running, the object will be recycled. Then, if a program accesses this object, the access will fail. On the other hand, to access a weak referenced object, the application must obtain a strong reference of the object. Therefore, GC cannot recycle the object because the object has a strong reference.
In addition, GC is recycled by generation or only partial heap is compressed to improve performance. GC generational collection is based on three assumptions: The shorter the new object lifecycle, and the longer the old object lifecycle; new objects are more correlated and frequently accessed.
Note: The GC algorithm is not static. To ensure performance optimization, It is a frequently adjusted part of CLR.