Optimization of garbage recovery performance
l Weak reference (Weakreference)
l generations (Generations)
Weak reference (Weakreference)
Weak references are a way to improve performance for reducing the pressure of large objects in the hosted stack.
When a root point to an object, it is called a strong reference to this object and this object cannot be recycled because the application can traverse this object.
When an object is a weak reference pointing to it (Weakreference), this object can be reclaimed if there is a memory request and the GC starts, and the object can be reclaimed. When the application is trying to access this object, the access will fail. On the other hand, in order to access an object that is weakly referenced (Weakreference), the application must obtain a strong reference to this object. If the application gets its strong reference before the garbage collector reclaims this object, the GC will not be able to recycle this object because there is a strong reference to this object.
The hosted stack contains two internal data structures of two management weak references: weak reference tables and long reference tables.
Two types of weak references:
l Weak reference does not track recovery.
That is, an object with a weak reference will be retracted immediately without waiting for the Finalize method.
l The weakest reference tracking recovery.
That is, the GC will only recover this object when the storage space of the object in the long reference table can be recovered. If the object has a Finalize method, it is called after the Finalize method is called and the object cannot be resurrected.
These two tables simply store pointers allocated in the hosted stack. Initially, both tables were empty. When you create a Weakreference object, the object does not assign from the hosted stack. Instead, an empty storage location is assigned in a weak reference table; the weak reference table uses a weak reference table, and the long reference table is used.
Let us look at an example to see what will happen when the GC is running. The following diagram (Figs. 1 and 2) show the state of all internal data structures before the GC operation and after the run.
Figure 1: GC operation
Figure 2: After the GC is running
The following is the operation of the GC runtime:
1. GC builds a picture for all traverse objects. In the above example, the diagram contains objects B, C, E, G.
2. GC scan shortage reference table. If the object to which the pointer points to the table is not in the figure, the pointer identifies an uncomidateable object, and this location in the weak reference table is NULL. In the above example, the position of the object D is set to NULL because it is not part of the figure.
3. GC scans the Finalization queue. If the object refers to the object in the queue is not in the figure, then this pointer identifies an ivable object, the pointer is moved from the Finalization queue to the FREACHABLE queue. At this time, the object is considered to be traversable, so add it to the figure. In the above example, the objects A, D, and F are not included in the figures but is considered to be traversable, because they belong to the Finalization queue. Furthermore, the Finalization queue is emptied.
4. GC Scanning Sweak Reference Table. If the object of the pointer in the table is not in the figure (now the object refers to the object referred to in the Freachable queue), the pointer identifies a non-traverse object, where the location is set to NULL. Since objects C and f are included in the figure, they do not place NULL.
5. GC Corruption (Compact) memory, extrusion cannot be traverse the void left by the object. In the above example, the object h is the only object that is unique from the heap, which is allocated by the memory. Generations
Since garbage collection is to be completed in the absence of the entire program, they may be interrupted during the program execution. GC is also possible to interrupt events that meet the needs of real-time systems and require a timely response.
There is a characteristic representation in the GC, which is specifically designed to improve performance. A multi-generation GC is obtained by careful analysis of two facts by multi-profile written in various languages:
1. The newly created object has a shorter life cycle.
2. The more old objects, the longer living.
Multi-generation recovers divide it into several groups through the age of objects, and young objects are more frequently recycled in older objects. When initialization, the hosted stack does not contain any objects. All new objects have been added to the 0th, until the stack is full and triggered garbage collection. Since most objects have a short period of time, only a small number of young objects survive in the first recovery. Once an object survives after the first recovery, it is raised to the first generation. It can be said that new objects can be said in the 0th-generation after garbage collection. The garbage recovery will only be triggered again when the pilot of the 0th generation is full. All 0th-generation objects are organized to the first generation. Then, the 0th generation does not contain any object, but all new objects have entered the 0th generation.
Therefore, as an object of "mature" (survived in a multi-generation recovery), they are moved to the next level. The second generation is the largest generation supported by the CLR GC. When recovered later, the 2nd generation survival object will only be simple to stay in the second generation.
Therefore, the objects of the buning are divided into objects and the recovery and finishing of young generations increase the efficiency of the garbage collection algorithm, because a large amount of meaningful space is recovered from the heap, while the recovery is checked in all generations. All objects are much faster.
A GC that can perform multi-generation recycling, each recycle must ensure that the time required for (at least as possible) is less than a maximum time to help do some real-time operations for real-time environment, but also prevent users from apparent I feel the interrupt.
Garbage recycling related myth
GC is obviously slower than manual memory management
Corresponding explanation: not necessarily. Modern garbage collector looks like running and manual storage allocation (Malloc / Free or New / Delete). In some special procedures, garbage collection is likely to be as fast as the user specifically designed custom memory. But from another aspect, in order to make the handmade memory management, the additional generation is added (for example, the reference count count) is often more expensive than GC.
GC will make program interrupt
Corresponding explanation: Since the garbage collector usually stops the entire application while looking and recycling garbage objects, they may result in too long interruption time and let the user aware. However, by the current optimization, these can feel completely avoided.
Handmade memory management does not cause interruption
Correspondence: Handmade memory management does not ensure performance. It may be interrupted due to a large number of allocation or release of memory.
The program with GC is large and bloated; GC is not suitable for small programs or systems
Corresponding explanation: Although it is very advantageous to use GC in a complex system, there is no reason to believe what GC will introduce what big overhead in other sizes.
I have heard that GC will use a lot of memory twice.
Correspondence: This may be a fact for the original GC, but not garbage collector is like this. The data structure used for GC is much larger than those manually managed.
