Memory Management in .NET

In .NET, memory is managed through the use of Managed Heaps. Generally, in case of other languages, memory is managed through the Operating System directly. The program is allocated with some specific amount of memory for its use from the Raw memory allocated by the Operating system and then used up by the program. In case of .NET environment, the memory is managed through the CLR (Common Language Runtime) directly and hence we call .NET memory management as Managed Memory Management.

Allocation of Memory

Generally .NET is hosted using Host process, during debugging .NET creates a process using VSHost.exe which gives the programmer the basic debugging facilities of the IDE and also direct managed memory management of the CLR. After deploying your application, the CLR creates the process in the name of its executable and allocates memory directly through Managed Heaps.

When CLR is loaded, generally two managed heaps are allocated; one is for small objects and the other for large objects. We generally call it as SOH (Small Object Heap) and LOH (Large Object Heap). Now when any process requests for memory, it transfers the request to CLR, it then assigns memory from these Managed Heaps based on their size. Generally, SOH is assigned for the memory request when size of the memory is less than 83 KBs( 85,000 bytes). If it is greater than this, it allocates memory from LOH. On more and more requests of memory, .NET commits memory in smaller chunks.

Now let’s come to processes. Generally, a process can invoke multiple threads, as multi-threading is supported in .NET directly. Now when a process creates a new thread, it creates its own stack, i.e., for the main thread .NET creates a new Stack which keeps track of all information associated with that particular thread. It keeps information regarding the current state of the thread, number of nested calls, etc. But every thread is using the same Heap for memory. That means, Heaps are shared through all threads.

Upon request of memory from a thread say, .NET allocates its memory from the shared Heap and moves its pointer to the next address location. This is in contrast to all other programming languages like C++ in which memory is allocated in linked lists directly managed by the Operating system, and each time memory requests is made by a process, Operating system searches for the big enough block. Still .NET win32 application has the limitation of maximum 2GB memory allocation for a single process.

32 bit processors have 32 bits of address space for locating a single byte of data. This means each 2^32 unique address locations that each byte of data can locate to, means 4.2 billion unique addresses (4GB). This 4GB memory is evenly distributed into two parts, 2 GB for Kernel and 2 GB for application usage.

De- Allocation of Memory

De - allocation of memory is also different from normal Win32 applications..NET has a sophisticated mechanism to de-allocate memory called Garbage Collector. Garbage Collector creates a thread that runs throughout the runtime environment, which traces through the code running under .NET. .NET keeps track of all the accessible paths to the objects in the code through the Graph of objects it creates. The relationships between the Object and the process associated with that object are maintained through a Graph. When garbage collection is triggered, it deems every object in the graph as garbage and traverses recursively to all the associated paths of the graph associated with the object looking for reachable objects. Every time the Garbage collector reaches an object, it marks the object as reachable. Now after finishing this task, garbage collector knows which objects are reachable and which aren’t. The unreachable objects are treated as Garbage to the garbage collector. Next, it releases all the unreachable objects and overwrites the unreachable objects with the reachable ones during the garbage collection process such that memory fragmentation does not occur. All unreachable objects are purged from the graph. Garbage collection is generally invoked when heap is getting exhausted or when application is exited or a process running under managed environment is killed.

Garbage collector generally doesn’t take an object as Garbage if it implements Finalize method. During the process of garbage collection, it first looks for the object finalization from metadata. If the object has implemented Finalize(), garbage collector doesn’t make this object as unreachable, but it is assigned to as Reachable and a reference of it is placed to the Finalization queue. Finalize is also handled by a separate thread called Finalizer thread which traces through the finalizer queue and calls the finalize of each of those objects and then marks for garbage collection. Thus, if an object is holding an expensive resource, the finalize should be used. But there is also a problem with this, if we use finalize method, the object may remain in memory for long even when the object is unreachable. Also, Finalize method is called through a separate thread, so there is no way to invoke it manually when the object life cycle ends.

Because of this, .NET provides a more sophisticated implementation of memory management called Dispose, which could be invoked manually during object destruction. The only thing that we need is to write the code to release memory in the Dispose and call it manually and not in finalize as Finalize() delays the garbage collection process.

Cost of Finalize in your Program

Now let us talk about the cost that you have to bear if you have implemented indeterministic approach of .NET and included Finalize in your class. To make it clear, you must know how GC works in CLR.

Generation 0 object means the objects that we have declared after last garbage collection is invoked. 1^st Generation objects means which is persisting for last 1 GC cycle. Likewise 2^nd Generation objects and so on. Now GC does imposes 10 examinies for 0 to 1 generation objects before doing actual Garbage Collection. For 1 to 2 Generation objects, it does 100 examinees before collecting.

Now let's think of Finalize, an object that implemented Finalize will remain 9 cycles more than it would be actually collected. If it still not finalized, it would move to Generation 2 and have to go through 100 examinees to be collected. Thus, use of Finalize is generally very expensive in your program.

IDisposable Implementation

For deterministic approach of resource deallocation, Microsoft introduced IDisposable interface to clear up all the resources that may be expensive.

Let us take an example:

Protected virtual void Dispose(bool isDisposing)
{
  if(IsDisposed) return;
  if(isDisposing)
  {
          // Dispose all Managed Resources
  }
  IsDisposed = true;
  GC.SuppressFinalize(this);
} 

Now let us explain.

The first line indicates an if condition statement. Here, I have checked if the object is already disposed or not. This is very essential, as in code one can call dispose multiple times, we need to always check whether the object is already disposed or not. Then we did the disposing, and then made IsDisposed to true.

Now GC.SuppressFinalize will suppress the call to finalize if it is there. This is because, if the user already disposed the object and cleared up all the expensive resources using deterministic approach of deallocation, we don't need the GC to wait to call Indeterministic Finalize method during the Garbage Collection process.

For local objects, we can call dispose directly after using the object. We can also make use of Using block or try/catch block for automatic disposal of objects.

Note: In case of USING, you must remember it works only with the objects that Implement IDisposable.

Also, it is advisable to not to call GC often in your program, as it will give an extra load to the JIT to accept your request rather than doing it itself, provided GC calls are taken as request.

Please read my 2^nd Blog entry on this topic from here:

• http://www.codeproject.com/Articles/38068/Best-Practices-of-Memory-Usage.aspx

Thank you for reading!