C # Memory Management-garbage collection

Chapter Arrangement

1. Memory Management Overview
2. Garbage Collection Mechanism
3. Performance problems
4. Processing of unmanaged resources in C #
5. Highlights
6. References

Memory Management Overview

Memory Management is a very important part of any programming language, but it is a pity that no programming language is perfect for memory management, each language focuses on both performance efficiency and syntax and semantics usability. For example, C ++, such as C # and Java, claims that garbage collection is not required, because C ++ produces a small amount of garbage. It is true that this is the advantage of C ++, this is why C ++ is preferred in an environment with limited memory or high efficiency, but its disadvantage is also obvious-the programmer must control the memory management by himself, and it is easy to cause memory leakage, this also makes C ++ difficult to grasp. Thanks to Moore's Law, it prompted the emergence of the concept of garbage collection, but compared with C ++ directly manipulating memory release, the junk collection algorithm cannot erase the performance loss of that layer.

Before the discussion, we should clarify that data in the memory can be divided into stack memory and heap memory by location, stack is mainly used to track data transfer between function calls (the data types stored on the stack are usually int, Char, long, pointer, and other built-in value types and struct. Note that in a multi-threaded environment, each thread has its own stack .) Therefore, the operating system is generally responsible for stack memory management. The memory management we talk about is mostly about memory management on the stack (the type allocated to the stack is generally custom reference type: Class, interface, String, object instance, C ). For more information, see under the hood of net management.

Memory management can be divided into three stages from the lifecycle: memory allocation, memory lifecycle management, and memory release. Each stage is closely related to the program running efficiency. Take C ++ as an example. In the new C ++ standard, unique_ptr replaces auto_ptr and move semantics, introducing right-value references greatly improves STL efficiency (For details, refer to the link on C ++ in refereces ). It is unrealistic to discuss all the content of memory management. This article focuses on the release of memory, which is exactly the garbage collection of C.

Garbage Collection Mechanism

First, we declare that garbage collection is the memory allocated to the managed stack. It is powerless for memory outside the managed stack.

We have to mention the allocation of memory when discussing the garbage collection mechanism. In the C-runtime heap, the heap is not continuous. When we create a new object, the system checks the memory, finds a large enough memory, and initializes the object. After the object is destroyed, the space is used to initialize a new object. What are the disadvantages of doing so? As the program runs, objects are generated and released, the memory will become fragmented. In this way, when a new large object is to be generated, the length of the heap must be extended, and the fragment memory cannot be fully utilized, another drawback is that heap memory should be checked every time an object is created, which is inefficient. The C # managed heap uses continuous memory storage. When creating a new object, you only need to consider whether the remaining heap memory is large enough, but the Continuous Generation of objects without destructor will infinitely increase the hosting heap. How to maintain such a continuous memory? This leads to the garbage collection mechanism. The size of the managed heap is specific. The Garbage Collector GC is responsible for releasing junk objects when the memory is insufficient, and copying objects into a continuous memory. This leads to performance problems. When the object is large, frequent copy moving objects will reduce the performance, therefore, the garbage collection of C # introduces the concept of generation and large object heap small object heap.

The so-called large object heap, small object heap, can be seen from the literal meaning, large object heap is mainly responsible for allocating large objects, small object heap is allocated small. But how can we determine the object size? In. NET Framework, if the object is greater than or equal to 85,000 bytes, it is considered a large object. After an object allocation request is passed in, if this threshold value is met, the object is allocated to a large object heap. The 85000 bytes are determined based on the performance optimization results. It is worth noting that garbage collection has an effect on both large object heap and small object heap. So what are the roles of large objects and small objects? Or performance. For large objects and small objects, it is better to adopt different flexible garbage collection policies than to adopt the same policy with a single stick. Next we will discuss different garbage collection policies in Soh and LOH:

Let's talk about the generation. The reason for generation division is that most objects can be cleared in the 0th generation. Please note that generation is a logical concept, and there is no data structure of generation physically. Taking small object heap garbage collection as an example: when an object is created, it is defined as a 0th generation object, after a garbage collection, the remaining objects are classified as 1st generation objects. Likewise, objects that still exist after two or more times can be considered as 2nd generation objects. Although the generation is only a logical concept, it has a size. For Soh objects, because every garbage collection will compress the moving objects, the larger the generation, the larger the heap. After a garbage collection, objects are moved into the memory space of the Next Generation (taking garbage collection on small objects as an example. The object W has been recycled for at least two times and does not die, so it is placed in generation 2 and X has undergone a garbage collection ). Each time the memory of a generation reaches its threshold, the garbage collector is recycled once. The advantage of doing so is that each Garbage Collector only recycles the memory of one generation. In general, it reduces the number of object replication moves.

The above discussion is aimed at soh. For Soh objects, copying and moving is a little less cost-effective than LOH. What about Loh? Copying a LOH object and clearing the word festival at the original memory location costs a lot. How can we ensure its garbage collection? First, physically, LOH is hosted on the heap bottom, And Soh is logically allocated to the second generation, that is to say, the garbage collection of the first and second generations is the Oh object, which explains why the first two generations of garbage collection allow copying and moving objects. But what about the second generation of garbage collection? After the second generation of garbage collection, objects are still in the second generation. During the collection, objects still in use are not moved, space is compressed, and garbage objects are only cleared. When a new LOH object is created, it searches for the memory that can satisfy the demand from the heap bottom traversal, if it is not created on the heap top (this process works the same way as the C runtime, so there are also the same drawbacks, and the LOH heap memory may have fragments ). If the threshold value is exceeded, the garbage collector recycles the memory space.

From the above discussion, we can sum up: When we create a new object, it will be put into the 0th generation, and the large object will be divided into LOH, only the garbage collector can "allocate" objects in the 1st and 2nd generations. The allocation object here refers to moving the replication object.

The above is the garbage collection mechanism. The most important thing is that the GC of the garbage collector determines how the object is a garbage object. For more information, see the link.

Performance problems

From the above discussion, we can see that automatic garbage collection requires cost, and the introduction of the concepts of generation and big object stack/small object stack is to minimize this cost. However, performance problems are inevitable. performance data analysis can help us understand and avoid some problems. For performance analysis tools and methods, see the references link.

C # Processing of unmanaged resources -- disposable Mode

As we have mentioned above, the garbage collector can only collect the memory of the managed heap, but for off-heap memory such as hwnds, database connection, GDI handle, and safehandle. In this case, there is a problem: the spam collector will not run in a definite way, and the result may make your object cannot be terminated for a long time after the last reference. If your object occupies expensive or scarce resources (such as a database connection), this is unacceptable. To avoid endless waiting for the garbage collector to run, the type of the resource should implement the idisposable interface, and then the users of this type of resource will release those resources in time. Joe Duff gave attention to details on his website and provided a disposable mode. You can refer to the link to learn more, so that your program is more elegant and robust. (This method is also used in the idisposable example on msdn)

Http://www.bluebytesoftware.com/blog/PermaLink.aspx? Guid = 88e62cdf-5919-4ac7-bc33-20c06ae539ae

Highlights

1. it is worth noting that although Microsoft does not move and compress LOH at present, it may be in the future. Therefore, if large objects are allocated and they want to be moved, they should be fixed.

2. This Article is based on my understanding and may vary. For more information, see the link.

 

References

C ++

Http://en.cppreference.com/w/

Http://zh.wikipedia.org/wiki/C++0x

Http://blog.csdn.net/zentropy/article/details/6973411

Http://www.codeproject.com/Articles/71540/Explicating-the-new-C-standard-C-0x-and-its-implem#RValues http://www.codeproject.com/Articles/101886/Standard-C-Library-Changes-in-Visual-C-2010

C #

Http://msdn.microsoft.com/zh-cn/magazine/bb985011 (En-US). aspx

Http://msdn.microsoft.com/zh-cn/magazine/cc534993.aspx

Http://www.bluebytesoftware.com/blog/PermaLink.aspx? Guid = 88e62cdf-5919-4ac7-bc33-20c06ae539ae

Performance issues and multi-language interaction

Http://msdn.microsoft.com/zh-cn/magazine/ee309515.aspx

Http://msdn.microsoft.com/zh-cn/magazine/cc163528.aspx

Http://msdn.microsoft.com/zh-cn/magazine/cc163316.aspx

Http://msdn.microsoft.com/zh-cn/magazine/cc163392.aspx

History of garbage collection:

Http://blog.csdn.net/KAI3000/article/details/314628

Http://blog.csdn.net/hellothere/article/details/2115422

Http://blog.csdn.net/hellothere/article/details/2245734

C # Memory Management-garbage collection