Complete and thorough analysis of the CLR: Disclosure of large Object heap

The CLR garbage collector (GC) divides objects into large, small, two classes. If it is a large object, some of its associated properties will be more important than the object. For example, the cost of compressing large objects (copying memory to other locations on the heap) is quite high. In this month's column, I'll delve into the large object heap. I'm going to talk about what criteria you can call a large object, how to recycle these large objects, and what the performance of large objects is.

Large Object Heap and GC

In the Microsoft®.net Framework 1.1 and 2.0, if the object is greater than or equal to 85,000 bytes, it is considered a large object. This number is determined based on the results of the performance optimization. When an object allocation request is passed in, the object is assigned to the large object heap if the size threshold is met. What the hell does that mean? To understand this, it may be helpful to understand some of the basics of the. NET garbage collector first.

As we all know, the. NET garbage collector is a generational collector. It contains three generations: the No. 0, 1th and 2nd generations. The reason for generational is that you can clear most objects in the No. 0 generation in a well tuned application. For example, in a server application, the allocation associated with each request is cleared after the request is completed. The allocation request that still exists will go to the 1th generation and be cleared there. In essence, the 1th generation is the buffer between the new object region and the longer-lifetime object region.

From a generational perspective, large objects belong to the 2nd generation because they can only be reclaimed during the 2nd generation of collections. When a generation is recycled, all previous generations are also recycled. For example, the 1th generation and the No. 0 generation are recycled when the 1th generation of garbage collection is performed. The entire heap is reclaimed when the 2nd generation of garbage collection is performed. Therefore, the 2nd generation of garbage collection is also known as complete garbage collection. In this column, I'll use the term "2nd generation garbage collection" instead of "full garbage collection," but they can be interchanged.

The generations of the garbage collector heap are logically divided. In fact, the object exists on the managed stack segment. A managed stack segment is a block of memory that the garbage collector represents managed code on the operating system by calling VirtualAlloc. When the CLR is loaded, two initial stack segments are allocated (one for small objects and another for large objects), which I call the small object Heap (SOH) and the large Object heap (LOH), respectively.

The allocation request is then satisfied by placing the managed object on any managed stack segment. If the object is less than 85,000 bytes, place it on the SOH segment, otherwise place it on the LOH segment. As more objects are allocated to each segment, the segments are submitted in smaller chunks.

For SOH, the unhandled objects of garbage collection will enter the next generation; this No. 0 generation of unhandled objects will be treated as a 1th generation object, and so on. However, the last generation of unhandled objects is still considered an object in the last generation. That is, the 2nd generation garbage Collection Unhandled object is still a 2nd generation object, and LOH objects are still LOH objects (reclaimed by the 2nd generation). User code can only be allocated in a No. 0 generation (Small object) or LOH (large object). Only the garbage collector can "allocate" objects in the 1th generation (by lifting the unhandled objects on generation No. 0) and in the 2nd generation (by lifting the unhandled objects by ascending the 1th and 2nd generations).

After the garbage collection is triggered, the garbage collector looks for existing objects and compresses them. For LOH, however, because of the high cost of compression, the CLR team chooses to sweep through all objects and list the objects that are not purged for later reuse, thus satisfying the allocation requests of large objects. The adjacent purged object will form a free object.