MEMORY MANAGEMENT IN .
NET
In .NET, memory is managed through the use of Managed Heaps. Generally, in case of other lan-
guages, 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, 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.
De- Allocation of Memory
.NET has a sophisticated mechanism to de-allocate memory called Garbage Collector. Garbage Col-
lector 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 as-
sociated 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
1
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.
Point to be remembered
Memory allocation
• Garbage Collector (GC) is the part of the .NET framework that allocates and releases memory
for your .NET applications.
• When a new process is started, the runtime reserves a region of address space for the process
called the managed heap.
• Objects are allocated in the heap contiguously one after another.
• Memory allocation is a very fast process as it is just the adding of a value to a pointer.
• In addition to the managed heap, an app always consumes some amount of so-called unmanaged
memory which is not managed by GC (Garbage Collector).
De-Allocation of Memory
• The process of releasing memory is called garbage collection.
• When GC performs a collection, it releases only objects that are no longer in use by the ap-
plication (for example, a local variable in a method can be accessed only during the method
execution and after this, the variable is no longer needed).
• To determine whether the object is used or not, GC examines application’s roots - strong ref-
erences that are global to the application. Typically, these are global and static object pointers,
local variables, and CPU registers. Learn more about possible GC roots in Analyze GC Roots.
• For each active root, GC builds a graph that contains all the objects that are reachable from
these roots.
• If an object is unreachable, GC considers it no longer in use and removes the object from the
heap (releases the memory occupied by the object).
• After the object is removed, GC compacts reachable objects in memory.
