MSDN Documentation

The Common Language Runtime (CLR) and Memory

The Common Language Runtime (CLR) is responsible for managing memory for .NET applications. It provides automatic memory management through a process known as garbage collection. This significantly simplifies development by relieving developers from manual memory allocation and deallocation.

The CLR allocates memory for managed code from a specific area called the managed heap. This heap is where objects are created and stored.

Managed vs. Unmanaged Code

.NET Core primarily deals with managed code, which runs under the control of the CLR. The CLR handles memory allocation, garbage collection, and security for managed code.

However, .NET Core can also interact with unmanaged code, which is code that runs outside the CLR's control, such as native C++ libraries. When interacting with unmanaged resources (like file handles, database connections, or graphics handles), developers are responsible for managing that memory explicitly to avoid resource leaks.

The Managed Heap

The managed heap is a dynamic memory region where all objects created by managed code reside. It's organized into different generations to optimize garbage collection.

The generations are:

• Generation 0: The youngest generation, where newly allocated objects are initially placed.
• Generation 1: Objects that have survived one or more garbage collections are promoted to this generation.
• Generation 2: Objects that have survived multiple garbage collections are promoted to this generation. This generation typically holds the longest-lived objects.

The garbage collector focuses its efforts on younger generations, as these are more likely to contain objects that are no longer in use.

Garbage Collection (GC)

Garbage collection is the automatic process of reclaiming memory occupied by objects that are no longer referenced by the application. When the CLR determines that an object is unreachable, it marks it for collection.

The GC works in cycles. When memory pressure is high or at specific intervals, the GC performs a "collection." During a collection:

1. Marking: The GC traverses the object graph starting from the application's roots (like static variables and stack variables) to identify all reachable objects.
2. Sweeping: The GC reclaims the memory occupied by unreachable objects.
3. Compacting: To prevent heap fragmentation, the GC can move the surviving objects together, leaving contiguous blocks of free memory.

Dispose Pattern and Finalizers

For managing unmanaged resources or other disposable objects, .NET Core provides the IDisposable interface. Implementing this interface and the Dispose() method allows you to explicitly release resources.

A typical IDisposable implementation looks like this:

public class MyResource : IDisposable
{
    private bool disposedValue = false; // To detect redundant calls

    protected virtual void Dispose(bool disposing)
    {
        if (!disposedValue)
        {
            if (disposing)
            {
                // TODO: Dispose managed state (managed objects)
            }

            // TODO: Free unmanaged resources (unmanaged objects) and override finalizer
            // TODO: Set large fields to null

            disposedValue = true;
        }
    }

    // // TODO: override finalizer only if 'Dispose(bool)' has code to free unmanaged resources
    // ~MyResource()
    // {
    //     // Do not change this code. Put cleanup code in 'Dispose(bool)' method
    //     Dispose(disposing: false);
    // }

    public void Dispose()
    {
        // Do not change this code. Put cleanup code in 'Dispose(bool)' method
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }
}
                

Finalizers (also known as destructors) are called by the GC before an object is collected if its Dispose() method was not called. They are a fallback for releasing unmanaged resources when explicit disposal is missed. However, relying heavily on finalizers can impact performance, as they add overhead to the GC process. It's always best to use the using statement or explicitly call Dispose() when working with IDisposable objects.

Using the using statement ensures that Dispose() is called automatically:

using (var myResource = new MyResource())
{
    // Use myResource here
} // myResource.Dispose() is automatically called here
                

Value Types vs. Reference Types

Understanding the difference between value types and reference types is key to how memory is managed:

• Value Types: (e.g., int, float, struct) are stored directly on the stack or inline within the object that contains them. When a value type is assigned to another variable, a copy of its value is made.
• Reference Types: (e.g., class, string, object) are stored on the managed heap. Variables that hold reference types store a reference (an address) to the object's location on the heap. When a reference type is assigned to another variable, only the reference is copied, not the object itself.