Automatic Memory Management of .NET Common Language Runtime and Garbage Collector Programming（.net 内存管理及垃圾收集器编程）

Table of Contents

1. What is Common Language Runtime 1

2. Managed and Unmanaged Resource 1

3. Memory management 2

3.1 Allocating Memory 2

3.2 Releasing Memory 2

3.3 Generations and Performance 3

3.4 Releasing Memory for Unmanaged Resources 4

4 Programming for Garbage Collection 4

4.1 C# Destructor Syntax 4

4.2 Implementing a Dispose Method 4

4.3 Forcing a Garbage Collection 7

References 8

1. What is Common Language Runtime

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative. It is Microsoft's implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. The CLR runs a form of bytecode called the Common Intermediate Language (CIL, previously known as MSIL -- Microsoft Intermediate Language).

Developers using the CLR write code in a language such as C# or VB.Net. At compile time, a .NET compiler converts such code into CIL code. At runtime, the CLR's just-in-time compiler converts the CIL code into code native to the operating system. Alternatively, the CIL code can be compiled to native code in a separate step prior to runtime. This speeds up all later runs of the software as the CIL-to-native compilation is no longer necessary.

The virtual machine aspect of the CLR allows programmers to ignore many details of the specific CPU that will execute the program. The CLR also provides other important services, including the following: Memory management , Thread management , Exception handling, Garbage collection and Security .

2. Managed and Unmanaged Resource

Managed Resource: Code executing under the control of the CLR is called managed code. For example, any code written in C# or Visual Basic .NET is managed code. Resource that can managed by CLR called Managed Resource.

Unmanaged Resource: Code that runs outside the CLR is referred to as "unmanaged code." COM components, ActiveX components, and Win32 API functions are examples of unmanaged code. And The most common type of unmanaged resource is an object that wraps an operating system resource, such as a file handle, window handle, or network connection. Although the garbage collector is able to track the lifetime of a managed object that encapsulates an unmanaged resource, it does not have specific knowledge about how to clean up the resource.

3. Memory management

3.1 Allocating Memory

When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner.

Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

3.2 Releasing Memory

The garbage collector's optimizing engine determines the best time to perform a collection based on the allocations being made. When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots. Every application has a set of roots. Each root either refers to an object on the managed heap or is set to null. An application's roots include global and static object pointers, local variables and reference object parameters on a thread's stack, and CPU registers. The garbage collector has access to the list of active roots that the just-in-time (JIT) compiler and the runtime maintain. Using this list, it examines an application's roots, and in the process creates a graph that contains all the objects that are reachable from the roots.

Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction.

To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

3.3 Generations and Performance

To optimize the performance of the garbage collector, the managed heap is divided into three generations: 0, 1, and 2. The runtmime allocates memory on generation 0 first. After the generation 0 is full. The garbage collector begins to reclaim the memory. At the same time all programs will be suspended. After finish this. The all reachable objects will be move to generation 1. Only when generation 0 can't reclaim memory. Then the garbage collector will run for generation 1. It has the same satiation for generation 2. See following for details.

The runtime's garbage collection algorithm is based on several generalizations that the computer software industry has discovered to be true by experimenting with garbage collection schemes. First, it is faster to compact the memory for a portion of the managed heap than for the entire managed heap. Secondly, newer objects will have shorter lifetimes and older objects will have longer lifetimes. Lastly, newer objects tend to be related to each other and accessed by the application around the same time.

The runtime's garbage collector stores new objects in generation 0. Objects created early in the application's lifetime that survive collections are promoted and stored in generations 1 and 2. The process of object promotion is described later in this topic. Because it is faster to compact a portion of the managed heap than the entire heap, this scheme allows the garbage collector to release the memory in a specific generation rather than release the memory for the entire managed heap each time it performs a collection.

In reality, the garbage collector performs a collection when generation 0 is full. If an application attempts to create a new object when generation 0 is full, the garbage collector discovers that there is no address space remaining in generation 0 to allocate for the object. The garbage collector performs a collection in an attempt to free address space in generation 0 for the object. The garbage collector starts by examining the objects in generation 0 rather than all objects in the managed heap. This is the most efficient approach, because new objects tend to have short lifetimes, and it is expected that many of the objects in generation 0 will no longer be in use by the application when a collection is performed. In addition, a collection of generation 0 alone often reclaims enough memory to allow the application to continue creating new objects.

After the garbage collector performs a collection of generation 0, it compacts the memory for the reachable objects as explained in Releasing Memory earlier in this topic. The garbage collector then promotes these objects and considers this portion of the managed heap generation 1. Because objects that survive collections tend to have longer lifetimes, it makes sense to promote them to a higher generation. As a result, the garbage collector does not have to reexamine the objects in generations 1 and 2 each time it performs a collection of generation 0.

After the garbage collector performs its first collection of generation 0 and promotes the reachable objects to generation 1, it considers the remainder of the managed heap generation 0. It continues to allocate memory for new objects in generation 0 until generation 0 is full and it is necessary to perform another collection. At this point, the garbage collector's optimizing engine determines whether it is necessary to examine the objects in older generations. For example, if a collection of generation 0 does not reclaim enough memory for the application to successfully complete its attempt to create a new object, the garbage collector can perform a collection of generation 1, then generation 0. If this does not reclaim enough memory, the garbage collector can perform a collection of generations 2, 1, and 0. After each collection, the garbage collector compacts the reachable objects in generation 0 and promotes them to generation 1. Objects in generation 1 that survive collections are promoted to generation 2. Because the garbage collector supports only three generations, objects in generation 2 that survive a collection remain in generation 2 until they are determined to be unreachable in a future collection.

3.4 Releasing Memory for Unmanaged Resources

For the majority of the objects that your application creates, you can rely on the garbage collector to automatically perform the necessary memory management tasks. However, unmanaged resources require explicit cleanup. The most common type of unmanaged resource is an object that wraps an operating system resource, such as a file handle, window handle, or network connection. Although the garbage collector is able to track the lifetime of a managed object that encapsulates an unmanaged resource, it does not have specific knowledge about how to clean up the resource. When you create an object that encapsulates an unmanaged resource, it is recommended that you provide the necessary code to clean up the unmanaged resource in a public Dispose method. By providing a Dispose method, you enable users of your object to explicitly free its memory when they are finished with the object. When you use an object that encapsulates an unmanaged resource, you should be aware of Dispose and call it as necessary.

4 Programming for Garbage Collection

4.1 C# Destructor Syntax

The Object.Finalize method can be used to release the memory resource. But we cannot call or override the Object.Finalize method from the C# or the Managed Extensions for C++ programming languages. We can use destructor syntax in C#.

The following code example is written for a destructor.

 
 

  
  
~MyClass()
{
   // Perform some cleanup operations here.
}
 
 
This code implicitly translates to the following. 


 
 

  
  
protected override void Finalize()
{
   try
   {
      // Perform some cleanup operations here.
   }
   finally
   {
      base.Finalize();
   }
}
 
 

4.2 Implementing a Dispose Method

A type's Dispose method should release all the resources that it owns. It should also release all resources owned by its base types by calling its parent type's Dispose method. A Dispose method should call the GC.SuppressFinalize method for the object it is disposing. If the object is currently on the finalization queue, GC.SuppressFinalize prevents its Finalize method from being called.

Example code:

1. // Design pattern for the base class.
2. // By implementing IDisposable, you are announcing that instances
3. // of this type allocate scarce resources.
4. public class BaseResource: IDisposable
5. {
6.    // Pointer to an external unmanaged resource.
7.    private IntPtr handle;
8.    // Other managed resource this class uses.
9.    private Component Components;
10.    // Track whether Dispose has been called.
11.    private bool disposed = false;
13.    // Constructor for the BaseResource object.
14.    public BaseResource()
15.    {
16.       // Insert appropriate constructor code here.
17.    }
19.    // Implement IDisposable.
20.    // Do not make this method virtual.
21.    // A derived class should not be able to override this method.
22.    public void Dispose()
23.    {
24.       Dispose(true);
25.       // Take yourself off the Finalization queue 
26.       // to prevent finalization code for this object
27.       // from executing a second time.
28.       GC.SuppressFinalize(this);
29.    }
31.    // Dispose(bool disposing) executes in two distinct scenarios.
32.    // If disposing equals true, the method has been called directly
33.    // or indirectly by a user's code. Managed and unmanaged resources
34.    // can be disposed.
35.    // If disposing equals false, the method has been called by the 
36.    // runtime from inside the finalizer and you should not reference 
37.    // other objects. Only unmanaged resources can be disposed.
38.    protected virtual void Dispose(bool disposing)
39.    {
40.       // Check to see if Dispose has already been called.
41.       if(!this.disposed)
42.       {
43.          // If disposing equals true, dispose all managed 
44.          // and unmanaged resources.
45.          if(disposing)
46.          {
47.             // Dispose managed resources.
48.             Components.Dispose();
49.          }
50.          // Release unmanaged resources. If disposing is false, 
51.          // only the following code is executed.
52.          CloseHandle(handle);
53.          handle = IntPtr.Zero;
54.          // Note that this is not thread safe.
55.          // Another thread could start disposing the object
56.          // after the managed resources are disposed,
57.          // but before the disposed flag is set to true.
58.          // If thread safety is necessary, it must be
59.          // implemented by the client.
61.       }
62.       disposed = true;         
63.    }
65.    // Use C# destructor syntax for finalization code.
66.    // This destructor will run only if the Dispose method 
67.    // does not get called.
68.    // It gives your base class the opportunity to finalize.
69.    // Do not provide destructors in types derived from this class.
70.    ~BaseResource()      
71.    {
72.       // Do not re-create Dispose clean-up code here.
73.       // Calling Dispose(false) is optimal in terms of
74.       // readability and maintainability.
75.       Dispose(false);
76.    }
78.    // Allow your Dispose method to be called multiple times,
79.    // but throw an exception if the object has been disposed.
80.    // Whenever you do something with this class, 
81.    // check to see if it has been disposed.
82.    public void DoSomething()
83.    {
84.       if(this.disposed)
85.       {
86.          throw new ObjectDisposedException();
87.       }
88.    }
89. }
91. // Design pattern for a derived class.
92. // Note that this derived class inherently implements the 
93. // IDisposable interface because it is implemented in the base class.
94. public class MyResourceWrapper: BaseResource
95. {
96.    // A managed resource that you add in this derived class.
97.    private ManagedResource addedManaged;
98.    // A native unmanaged resource that you add in this derived class.
99.    private NativeResource addedNative;
100.    private bool disposed = false;
102.   // Constructor for this object.
103.    public MyResourceWrapper()
104.    {
105.       // Insert appropriate constructor code here.
106.    }
108.    protected override void Dispose(bool disposing)
109.    {
110.       if(!this.disposed)
111.       {
112.          try
113.          {
114.             if(disposing)
115.             {
116.                // Release the managed resources you added in
117.                // this derived class here.
118.                addedManaged.Dispose();         
119.             }
120.             // Release the native unmanaged resources you added
121.             // in this derived class here.
122.             CloseHandle(addedNative);
123.             this.disposed = true;
124.          }
125.          finally
126.          {
127.             // Call Dispose on your base class.
128.             base.Dispose(disposing);
129.          }
130.       }
131.    }
132. }
134. // This derived class does not have a Finalize method
135. // or a Dispose method without parameters because it inherits 
136. // them from the base class.

4.3 Forcing a Garbage Collection

The garbage collection GC class provides the GC.Collect method, which you can use to give your application some direct control over the garbage collector. In general, you should avoid calling any of the collect methods and allow the garbage collector to run independently. You should also be careful not to place code that calls GC.Collect at a point in your program where users could call it frequently. This would defeat the optimizing engine in the garbage collector, which determines the best time to run a garbage collection.

t might be appropriate to use the GC.Collect method in a situation where there is a significant reduction in the amount of memory being used at a defined point in your application's code. For example, an application might use a document that references a significant number of unmanaged resources. When your application closes the document, you know definitively that the resources the document has been using are no longer needed. For performance reasons, it makes sense to release them all at once.

Example code:

1. using System;
3. namespace GCCollectExample
4. {
5.     class MyGCCollectClass
6.     {
7.         private const int maxGarbage = 1000;
9.         static void Main()
10.         {
11.             // Put some objects in memory.
12.             MyGCCollectClass.MakeSomeGarbage();
13.             Console.WriteLine("Memory used before collection: {0}", GC.GetTotalMemory(false));
14.          
15.             // Collect all generations of memory.
16.             GC.Collect();
17.             Console.WriteLine("Memory used after full collection: {0}", GC.GetTotalMemory(true));
18.         }
20.         static void MakeSomeGarbage()
21.         {
22.             Version vt;
24.             for(int i = 0; i < maxGarbage; i++)
25.             {
26.                 // Create objects and release them to fill up memory
27.                 // with unused objects.
28.                 vt = new Version();
29.             }
30.         }
31.     }
32. }

References

1. http://en.wikipedia.org/wiki/Common_Language_Runtime

2. http://msdn.microsoft.com/en-us/library/ms973872.aspx#manunman_mancode

3. http://msdn.microsoft.com/en-us/library/f144e03t(VS.71).aspx

4. http://msdn.microsoft.com/en-us/library/0xy59wtx(VS.71).aspx