What these terms actually mean
- Automatic Memory Management
- Allocating Memory
- Releasing Memory
- Generations and Performance
π Automatic Memory Management
During managed execution, the CLR provides a service called automatic memory management, which takes care of allocating and releasing memory for your application. This means developers don't need to write manual memory management code anymore.
It also prevents two of the most common mistakes in manual memory handling
- Forgetting to free unused objects, which leads to memory leaks
- Trying to access memory that has already been released
π Allocating Memory
When a process starts, the runtime reserves a continuous block of memory address space for it, known as the Managed Heap. The starting point of this heap is called the Base Address, and the runtime keeps a pointer there to indicate where new memory can be allocated.
When your application creates its first reference type, it's placed right at the Base Address of the Managed Heap. The next object goes right after it, and so on. As long as there's enough address space, new objects are laid out one after another. Once the space runs out, the Garbage Collector (GC) kicks in to release memory.
π Releasing Memory
Every application has a set of roots, which reference objects on the Managed Heap or are set to null. An application's roots include static fields, local variables and parameters on a thread's stack, CPU registers, GC handles, and the finalize queue.
When the GC runs, it:
- Checks which objects on the Managed Heap are still referenced by the application's roots
- Finds the objects that are no longer in use
- Frees the memory occupied by unused objects, and compacts the remaining ones to make memory contiguous again
- Updates all pointers so that the roots now reference the objects at their new addresses
The GC's optimization engine decides when it's the best time to collect, based on system state and memory usage. When it runs, it identifies objects that are no longer used and reclaims their memory space.
π Generations and Performance
In .NET, the Managed Heap is divided into three generations to improve performance
- Generation 0
- Generation 1
- Generation 2
When new objects are created, they're first placed in Generation 0. As the app runs, objects that survive multiple garbage collections are promoted to Generation 1 and eventually Generation 2.
Initially, new objects go into Gen 0. When Gen 0 runs out of space, the GC runs a collection, freeing memory from objects that are no longer used. If an object survives multiple collections, it gets promoted to Gen 1 β basically meaning it has a longer lifetime. If after collecting Gen 0, there's still not enough free memory, the GC will continue with Gen 1 or Gen 2 collections.
The .NET GC is based on the assumption that most objects are short-lived. Scanning the entire Managed Heap every time would be too expensive, it would mean moving and rearranging everything constantly. That's why the GC divides the heap into generations, it can focus on newer objects first and only move on to older generations when necessary. This keeps memory management efficient without constantly touching every object.
π‘ Key Points
- The CLR's automatic memory management frees developers from handling memory manually and helps prevent memory leaks and invalid reference.
- The runtime allocates objects continuously on the Managed Heap, when space runs out, the GC reclaims memory from unused objects.
- The GC scans the application's roots, identifies unreferenced objects, releases them, compacts surviving ones, and updates references to reduce fragmentation.
- The GC divides objects into three generations β Gen 0, Gen 1, Gen 2 β based on their lifetime.
- It prioritizes collecting Gen 0 objects and only scans older generations when needed, reducing unnecessary object movement.
Easy, right? Job done βοΈ
Thanks for reading!
If you like this article, please don't hesitate to click the heart button β€οΈ
or follow my GitHub I'd appreciate it.
Top comments (0)