CLR series: Large Object heap

Many people in the garden have already had a heated discussion about the GC heap of CLR, which has many excellent features.Article. However, since it is a CLR series, we have to explain GC heap. This article focuses on Loh(Large Object heap.After a managed process is created, it containsSystem domain,Shared domain,Default domain,ProcessOfHeap,JIT code heap (all contained in loaderheap),GC heapAndLoh.

 

The CLR garbage collector (GC) divides objects into two types: large and small. If it is a large object, its related attributes are more important than the object's hour. For example, the cost of compressing large objects (copying memory to other locations on the heap) is quite high. I will discuss what qualified objects can be called large objects, how to recycle these large objects, and what performance significance large objects have.

 

Large Object heap

In. NET Framework 1.1 and 2.0, objects larger than or equal to 85,000 bytes are considered as large objects. Note:This number is determined based on the performance optimization results.. After the object allocation request is passed in, if the object meets the size, the object will be allocated to the large object heap. Why? Let's first look at the basic knowledge of the net garbage collector.

 

We know that the. NET garbage collector is a generational recycler. It contains three generations: 0th, 1st, and 2nd. The reason for generation division is that it is used for excellent optimization.Program, You can clear most objects in generation 0th. Every time a garbage collection is triggered, net first scans the 0th generation, and the existing objects will be placed in the 1st generation. When the 1st generation is full, the 1st generation will be reclaimed, the existing objects will be placed in the 2nd generation for this purpose. However, the last generation will still be treated as the objects in the last generation. Essentially, the 1st generation is the buffer zone between the new object region and the object region with a long lifetime. Any generation will be recycled from all previous generations. For example, the 1st and 1st generations of garbage collection will be recycled at the same time. The entire heap will be reclaimed when the 2nd-generation garbage collection is executed.

When the CLR is loaded, two initial stack segments will be allocated (one for small objects and the other for large objects). I will call them small object heaps (SOH) and large object heap (LOH ). Then, the allocation request is met by placing the managed object in any managed stack segment. If the object is smaller than 85,000 bytes, it is placed on the Soh segment; otherwise, it is placed on the LOH segment. As more and more objects are allocated to each segment, these segments are submitted in smaller pieces. UserCodeIt can only be allocated in generation 0th (small object) or LOH (large object. Only the garbage collector can recycle unprocessed objects in the 1st generation (by upgrading the 0th generation) and the 2nd generation (by upgrading the 1st generation and 2nd generation to recycle unprocessed objects). After garbage collection is triggered, the garbage collector searches for existing objects and compresses them. If there is not enough available space to accommodate large object allocation requests, I will first try to get more segments from the operating system. If it fails, I will trigger 2nd generation garbage collection to release some space.

If you still have doubts, you can look at the following windbg + SOSLet's take a look at a user-running programGC heapWhat is in it:

Number of GC heaps: 1
Generation 0 starts at 0x013d1018
Generation 1 starts at 0x013d100c
Generation 2 starts at 0x013d1000
Ephemeral segment allocation context: None
Segment begin allocated size
001b09f8 7a733370 7a754b98 0x00021828 (137256)
001b3fc0 7b463c40 7b47a744 0x00016b04 (92932)
0014df68 790d8620 790f7d8c 0x0001f76c (128876)
013d0000 013d1000 01425ff4 0x00054ff4 (348148)
Large Object heap starts at 0x023d1000
Segment begin allocated size
023d0000 023d1000 023d8e00 0x00007e00 (32256)
Total size 0xb488c (739468)
------------------------------
GC heap size 0xb488c (739468)
One of us GC heap There are four Heap segment , Followed Heap segment Yes Loh . Generation heap segment . A heap segment can contain two generation three or more. A generation can span multiple heap segment . memory area next to GC heap , is LOH . By default, the objects that exceed 85000 bytes are saved here.

 

When to recycle large objects Allocation exceeds 0th generation or large object threshold Call system. gc. Collect If GC. Collect is called for the 2nd generation, LOH and other managed heaps will be recycled immediately. System memory is too low Loh Performance CLR scans all objects to check whether the object references other objects. If so, these objects will be stored together, and objects that are not referenced by other objects will be stored in another region. This is based on performance considerations. Let's take a look at the recovery costs. As mentioned above, LOH and generation 2nd will be recycled together. If any of the two thresholds is exceeded, 2nd-generation recovery is triggered. If 2nd is triggered for lOh, the 2nd generation itself may not necessarily become smaller after garbage collection. Therefore, if there is not much data in the 2nd generation, this will not be a problem. However, if the 2nd generation is large, triggering multiple 2nd generation garbage collection may cause performance problems. Without a doubt, if you continue to allocate and process real large objects, the allocation cost will definitely increase significantly. Let's take a look at the above debugging results. We can see large object heap starts at 0x023d1000
Segment begin allocated size
023d0000 023d1000 023d8e00 0x00007e00 (32256) The total LOH size is less than 85,000 bytes. Why? This is because the runtime actually uses LOH to allocate objects smaller than large objects. Check the following debugging code (Loh memory segment) at>! Dumpheap-stat 023d1000 023d8e00
Total 17 objects
Statistics:
Mt count totalsize Class Name
0014c090 9 144 free
7912d8f8 8 32112 system. object []
Total 17 objects
Large objects are expensive. Since CLR needs to clear some memory for newly allocated large objects to ensure that CLR can clear all memory for newly allocated objects, the allocation cost is quite high. Loh will be recycled together with the rest of the heap. If you can, we recommend that you re-use large objects to avoid hosting the heap. The extra-large objects on the LOH are usually arrays (there are very few very large instance objects ). If the array element contains many references, the cost will be high. If the element does not contain any references, you do not need to process the array at all. Finally, LOH cannot be compressed in the recycling process until now, but it should not be dependent on this implementation. Therefore, to ensure that some content is not moved by GC, always fix it.