Shulou(Shulou.com)06/02 Report--

How to carry out .net garbage collection and large object handling, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

The CLR garbage collector divides objects according to the amount of space occupied. There is a big difference between large objects and small objects. For example, memory defragmentation-moving large objects in memory is expensive. Let's take a look at how the garbage collector handles large objects and what potential effects large objects have on program performance.

Large object heap and garbage collection

In .net 1.0 and 2.0, an object is considered to be a large object if it is larger than 85000byte. This figure is based on experience in performance optimization. When an object requests memory size to reach this threshold, it is allocated to the large object heap. What does that mean? To understand this, we need to understand the .net garbage collection mechanism.

As most people know, .Net GC is recycled according to "generation". There are three generations of objects in the program, namely, 0 generation, 1 generation and 2 generations. the 0 generation is the youngest and the second generation is the longest. GC garbage collection by generation is also for performance reasons; usually objects are recycled in generation 0. For example, in an asp.net program, the objects associated with each request should be recycled at the end of the request. Objects that are not recycled become first-generation objects; that is, first-generation objects are a buffer between resident memory objects and immediately dead objects.

From a generational point of view, large objects belong to generation 2 objects, because large objects are processed only when they are recycled by generation 2. When a generation of garbage collection is performed, a younger generation of garbage collection is performed at the same time. For example, when the first generation garbage collection, both generation 1 and generation 0 objects will be recycled, and when the second generation garbage collection will be performed, the first generation and the zero generation will be recycled.

Instead, the garbage collector distinguishes the logical view of the memory area. From a physical storage point of view, objects are allocated on different managed heaps. A managed heap (managed heap) is the area of memory that the garbage collector requests from the operating system (by calling windows api VirtualAlloc). When CLR is loaded into memory, two managed heaps, a large object large object heap (LOH-heap) and a small object pair (SOH-small object heap), are initialized.

The memory allocation request is to put the managed object on the corresponding managed heap. If the size of the object is less than 85000byte, it will be placed on SOH; otherwise it will be placed on LOH.

For SOH, the object moves on to the next generation after performing a garbage collection. In other words, if the surviving object enters the second generation when garbage collection is performed for the second time, and if the object is not collected as garbage after the second garbage collection, it will become the second generation object; the second generation object is the oldest object will not be promoted algebra.

When garbage collection is triggered, the garbage collector defragments the small object heap to move the surviving objects together. As for the large object heap, because of the high overhead of moving memory, the CLR team chose to just clear them and form a list of recycled objects so that the next time a large object applied for memory, the adjacent garbage objects would be merged into a free memory block.

It is important to keep in mind that large object heaps are not defragmented until .net 4.0, and may be done in the future. So if you want to allocate large objects and don't want them to be moved, you can use the fix statement.

The following is the recycling diagram of the small object heap SOH

The following figure is a schematic diagram of large object heap LOH recycling.

You can see that before garbage collection, a total of four objects obj0-3 were collected * obj1 and obj2 were collected after the second generation garbage collection, and the space occupied by obj1 and obj2 was merged after collection, and the space released by obj1 and obj2 was allocated to it when obj4 applied for memory allocation; at the same time, it left a piece of memory fragment. If the size of the fragment is smaller than 85000byte, then the fragment can never be reused during the lifetime of the program.

If there is not enough free memory on the large object heap to accommodate the large object space to be applied for, CLR will first try to apply for memory from the operating system, and if the application fails, it will trigger a second-generation recycling to try to free some memory.

In the second generation of garbage collection, unwanted memory can be returned to the operating system through VirtualFree. For the return process, see the following figure:

When will the large objects be recycled?

Before discussing when to collect large objects, let's take a look at when ordinary garbage collection operations are performed. Garbage collection occurs in the following situations:

1. The requested space exceeds the 0-generation memory size or the threshold of the large object heap, and most managed heap garbage collection occurs in this case

two。 When the GC.Collect method is called in the program code, garbage collection of all generation objects, including garbage collection of large object heaps, will be performed if the GC.Collect method is called with a GC.MaxGeneration parameter

3. When the operating system is out of memory, when the application receives a high memory notification from the operating system

4. If the garbage collection algorithm thinks that the second generation recycling is effective, it will trigger the second generation garbage collection.

5. Each generation of object heap has a property of the size threshold of the occupied space. When you allocate objects to a certain generation, you increase the total amount of memory close to the threshold of that generation, or allocate objects so that the heap size of this generation exceeds the heap threshold. A garbage collection occurs. So when you allocate small or large objects, you will consume the threshold of generation 0 or large object heap. When the garbage collector promotes the object algebra to the first or second generation, it consumes the threshold of the first or second generation. These thresholds change dynamically during the operation of the program.

Performance impact of large object heap

Let's first take a look at the cost of allocating large objects. When CLR allocates memory for each new object, make sure that the memory is empty and is not used by other objects (I give out is cleared). This means that the cost allocated is completely controlled by the cost of clearing (unless a garbage collection is triggered at the time of allocation). If it takes 2 cycles (cycles) to empty the 1byte, it means that it takes 170000 cycles to clear the smallest large object. In general, people do not allocate oversized objects, such as 16m objects on 2GHz machines, and it takes about 16ms to empty memory. The price is too high.

Let's take a look at the cost of recycling. As mentioned earlier, large objects are recycled with 2-generation-old objects. If the space occupied by a large object or a second-generation object exceeds its threshold, the recycling of the second-generation object will be triggered. If Gen 2 recycling is triggered because the large object heap exceeds the threshold, Gen 2 object heap itself does not have many objects to recycle. If there are not many objects on the second generation heap, this is not a big problem. But if the second generation heap is very large and there are many objects, too much second generation recycling will cause performance problems. If it is a temporary allocation of large objects, it will take a lot of time to run garbage collection; that is, if you continue to use large objects and then release large objects will have a big negative impact on performance.

Large objects on a large object heap are usually arrays (it is rare for an object to be very large). If the elements in the object are strong references, the cost can be high; if the elements do not refer to each other, there is no need to traverse the entire array for garbage collection. For example, to use an array to save the nodes of a binary tree, one way is to strongly reference the left and right nodes in the nodes:

Class Node {Data d; Node left; Node right;} Node [] binaryTree = new Node [num _ nodes]

If num_nodes is a large number, it means that each node needs to view at least two reference elements. One alternative is to save the array index numbers of the left and right node elements in the node

Class Node {Data d; uint left_index; uint right_index;}

In this way, the reference relationship between elements is removed; the referenced node can be obtained through binaryTree [left _ index]. The garbage collector does not need to look at the relevant reference elements when doing garbage collection.

Collect performance data for a large object heap

There are several ways to collect performance data related to large object heaps. Before I explain these methods, let's talk about why we need to collect performance data related to large object heaps.

When you start collecting performance data on some aspect, it's possible that you've found evidence of a performance bottleneck, or you haven't found a problem in all aspects.

Net CLR Memory performance counters are usually the tools that should be considered first when looking for performance problems. Counters related to LOH are generation 2 collectioins (number of 2 heap collections) and large object heap size large object heap size. The Generation 2 collections shows the number of 2 generations of garbage collection operations that have occurred since the process started. The Large object heap size counter shows the current size of the large object heap, including free space; this counter is updated after each garbage collection operation, not every time memory is allocated.

You can refer to the following figure to observe the relevant performance data of .net CLR Memory in the windows performance counter.

You can also query the values of these counters through programs; many people collect performance counters programmatically to help find performance bottlenecks.

Of course, you can also use the debugger winddbg to observe the large object heap.

A hint: so far, large object heaps are not defragmented as part of garbage collection, but this is only an implementation detail of clr, and program code should not rely on this feature. If you want to ensure that the object is not moved by the garbage collector, use the fixed statement.

After reading the above, have you mastered how to do .net garbage collection and large object handling? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.