Section Tenth: Generation

Generation is a mechanism of CLR garbage collection, its sole purpose is to improve the performance of the application, and a generation-based garbage collector makes the following assumptions.

1. The more new The object, the shorter the lifetime.
2. The older the object, the longer the lifetime.
3. The heap is recycled to a fraction faster than the entire heap is recycled.

Countless studies have shown that these assumptions are true for most applications today, and these assumptions affect how the garbage collector is implemented. This section explains how the generation works.

When the managed heap is initialized, it does not contain any objects, which are added to the heap object called the No. 0 generation object. Simply put, the No. 0 generation objects are those newly constructed objects, and the garbage collector never checks them. Shows a newly launched application that allocates 5 objects (from A to e). After a while, objects C and E became unreachable.

When the CLR initializes, it selects a budget container for the No. 0 generation object, assuming 256KB (the actual capacity may vary). Therefore, if you assign a new object that causes the No. 0 generation to exceed the budget, you must start a garbage collection.

Suppose the object a-e occupies just 256K. When object F is allocated, the garbage collector must start. The garbage collector determines that objects C and e are garbage compressed (defragmented) object D so that it is adjacent to object B, and by the way, the No. 0 generation of the budget container is 256K because all of these objects can be loaded into the CPU's L2 cache, so that the compression of the memory can be done at a very fast speed. objects that survive in garbage collection are considered 1th generation objects. The 1th generation object has undergone a check of the garbage collector as shown below:

After a garbage collection, the No. 0 generation does not contain any objects. As before, the new object is assigned to the No. 0 generation. As shown, the application continues to run, and new objects F to K are assigned, and as the application continues to run, objects B, H, G become unreachable, their memory is recycled at some point,

Now assume that allocating new objects L will cause the No. 0 generation to exceed its 256K budget. Because the No. 0 generation has reached the budget, garbage collection must be started. When you start a garbage collection, the garbage collector must decide which generations to check. As I said earlier, when the CLR was initially, it chose a budget for the No. 0 generation object. Similarly, it must select a budget for the 1th generation, assuming that the budget chosen for the 1th generation is 2MB.

When you start a garbage collection, the garbage collector also checks how much memory the 1th generation occupies. In this case, because the 1th generation occupies much less than 2MB of memory, the garbage collector examines only the No. 0 generation of objects and reviews the assumptions made by the generation-based garbage collector, the first assumption being that the newly created object has a short lifetime. Therefore, the No. 0 generation may contain a lot of garbage, so for the No. 0 generation recovery, more memory may be recycled. The garbage collection period ignores objects in the 1th generation, which speeds up garbage collection.

Obviously, ignoring objects in the 1th generation can enhance the performance of the garbage collector. However, a more powerful boost to performance is that it is now not necessary to traverse every object in the managed heap. If a root or an object refers to an object of an older generation. The garbage collector can ignore all the internal references of an old object, allowing it to construct a well-reached object graph faster. Of course, the fields of the old object may also refer to the new object. To ensure that these updated fields in the old object are checked, the garbage collector takes advantage of a mechanism inside the JIT compiler. This mechanism updates a bit flag when the object's Reference field changes, so that the garbage collection period knows which old objects have been written since the last garbage collection. Only old objects that have changed fields need to check if any new objects in generation No. 0 are referenced.

The generation-based garbage collector also assumes that the longer-lived objects will continue to live. In other words, the 1th generation object is likely to continue to be accessible in the application. If the garbage collector checks that the 1th generation of objects is likely to find little garbage, the result is not much memory being recycled. Therefore, the 1th generation of garbage collection is likely to be a waste of time, if there is really rubbish in the 1th generation, it will stay there.

All surviving No. 0-generation objects are promoted to part of the 1th generation. Because the garbage collector did not check the 1th generation, Object B's memory was not recycled, and it was not available at the time of the last garbage collection. Similarly, after a garbage collection, the No. 0 generation object does not contain any objects and waits for the new object to be allocated. Assuming the application continues to run and allocates objects L to object o, in addition, the application stops using objects g,l and M during the run, making them inaccessible,

It is assumed that the allocation object P causes the No. 0 generation object to exceed the budget, and garbage collection occurs. Since the memory occupied by the 1th generation object is still less than 2MB, the garbage collection period again decides to reclaim only the No. 0 generation, ignoring objects that are not unreachable in the 1th generation.

After recycling, the heap is as follows:

The first generation of objects is slowly growing. Assuming that the 1th generation of growth causes all of its objects to occupy 2MB of memory. At this point, the application continues to run and assigns the object p to s so that the No. 0-generation object reaches its budget capacity. The heap looks like this:

When an application tries to allocate an object T, it must start garbage collection because the No. 0 generation is full, but this garbage collection finds that the 1th generation occupies too much memory to reach the 1th-generation 2Mb budget. As a result of the previous collection of the No. 0 generation, the 1th generation has been a lot of objects become unreachable, so this time garbage collection decided to check all the 1th and No. 0 objects, both are recycled, the heap is as follows:

As shown:

As before, garbage collection, the No. 0 generation of survivors were promoted to the 1th generation, the 1th generation of survivors were promoted to the 2nd generation, No. 0 generation again vacated, ready to meet the arrival of new objects. The second object has been checked for at least 2 or more times. Although many garbage collections have occurred so far, the objects in the 1th generation are only checked when the 1th generation reaches its budget. Prior to this, the No. 0 generation was generally carried out several times garbage collection.

The CLR's managed heap supports only 3 generations: No. 0 generation, 1th generation, 2nd generation. No 3rd generation. When the CLR initializes, the budget is selected for each generation. As shown earlier, the No. 0 generation of the budget is about 256K, the 1th generation about 2mb,d 2nd generation about 10MB, the same. The size of the budget to improve performance is appropriate, the larger the budget, the lower the frequency of garbage collection. Again, the performance boost stems from the initial assumption that the new object has a shorter lifetime and the older objects tend to live longer. The CLR's garbage collection period is self-tuning. This means that the garbage collection period will understand the behavior of the application during garbage collection. For example, suppose an application constructs many objects, but each object takes a very short time, in which case a garbage collection of generation No. 0 reclaims a lot of memory. In fact, all objects in the No. 0 generation may be recycled.

If the garbage collection period finds that fewer objects survived after 0 generations, it is possible to reduce the No. 0-generation budget from 256KB to 128kB and the reduced allocated space, which means that garbage collection will occur more frequently, but the garbage collector needs more work to reduce the working set of the process. In fact, if the No. 0-generation object is garbage, the garbage collection period does not have to compress any memory, just let the pointer (NEXTOBJPTR) refer back to the beginning of the No. 0 generation.

On the other hand, if the garbage collector recycles the No. 0 generation and finds that there are many more objects alive, and not much memory is being recycled, it will increase the NO. 0-generation budget, such as 521KB, and now the number of garbage collections is reduced, but the amount of memory reclaimed is much larger each time it is recycled. If you do not recycle enough memory, the garbage collector performs a full garbage collection. If not enough, run out of outofmemoryexception anomalies.

So far, I've only discussed how to dynamically adjust the No. 0-generation budget after garbage collection. However, the garbage collector will also use a similar heuristic algorithm to adjust the budget for 1th and 2nd generations, when these generations are garbage collected, the garbage collector checks how much memory is being reclaimed and how many objects survived, and based on these results the garbage collector may want to increase or decrease the budget for these generations. This improves the overall performance of your application. The end result is that the garbage collector automatically optimizes based on the memory load required by the application.

Section Tenth: Generation