add: managed heap

Author: MVSharp

src/content/posts/NET/Heap/Heap.md

@@ -1,10 +1,74 @@
 ---
 title: "CLR Managed Heaps In .NET"
-published: 2025-08-04
+published: 2025-08-10
 description: "Some notes during the time i study CLR Managed Heap.NET"
 image: "./heapAreaView.svg"
 tags: [DOTNET, CSharp]
 category: "DOTNET"
 draft: false
 lang: "en"
 ---
+
+# Understanding CLR Managed Heaps in .NET
+
+The Common Language Runtime (CLR) is the heart of the .NET ecosystem, responsible for managing the execution of .NET applications. One of its critical components is memory management, which is handled through various heaps. These heaps are specialized memory regions designed to optimize performance, garbage collection, and resource allocation. In this article, we delve into two primary categories: Loader Heaps and Managed Heaps. We'll explore their subcomponents, purposes, and how they contribute to efficient .NET application runtime.
+
+## Loader Heaps
+
+Loader Heaps are part of the CLR's internal memory management system, primarily used for storing metadata, code, and other runtime structures that are not subject to garbage collection. These heaps are created and managed by the CLR loader, which is responsible for loading assemblies, types, and methods. Unlike managed heaps, loader heaps are not generational and grow monotonically until the process terminates. They are divided into several specialized sub-heaps to handle different types of data with varying allocation frequencies and lifetimes.
+
+### High Frequency Heap
+
+The High Frequency Heap is optimized for frequent allocations of small, short-lived objects. It is used for structures that are created and discarded rapidly during the CLR's operation, such as temporary buffers or small metadata entries. This heap employs a fast allocation mechanism to minimize overhead, ensuring that high-throughput operations like method invocations or type resolutions do not bottleneck the system.
+
+### Low Frequency Heap
+
+In contrast, the Low Frequency Heap handles allocations that occur less often but may involve larger or longer-lived objects. This includes assembly metadata, module information, and other static data that persists for the duration of the application domain. By segregating these from high-frequency allocations, the CLR reduces fragmentation and improves cache locality.
+
+### Stub Heap
+
+The Stub Heap is dedicated to storing stubs, which are small pieces of code that act as intermediaries for method calls. These include thunks for P/Invoke calls, delegate invocations, and interface dispatch. Stubs are generated dynamically and stored here to facilitate seamless transitions between managed and unmanaged code or to handle virtual method resolutions efficiently.
+
+### JIT Heap
+
+The Just-In-Time (JIT) Heap stores compiled native code generated by the JIT compiler. When managed methods are executed for the first time, the CLR compiles IL (Intermediate Language) to machine code and allocates space for it in this heap. This heap is crucial for performance, as it holds the executable instructions that run the application. It grows as more methods are JIT-compiled, and the code remains valid until the application domain is unloaded.
+
+### VCS Heap
+
+The Version Control System (VCS) Heap, also known as the Version-Compatible Serialization Heap, manages data related to serialization and deserialization processes that require version tolerance. It stores type information and serializers for objects that need to be persisted or transmitted across different .NET versions, ensuring compatibility and backward/forward serialization support.
+
+### Process/Base Heap
+
+The Process/Base Heap serves as the foundational heap for the CLR process. It allocates memory for core runtime structures, such as the execution engine, thread pools, and global variables. This heap is initialized early in the process lifetime and provides the base memory pool from which other loader heaps may derive or reference. It is essential for the overall stability and initialization of the CLR environment.
+
+## Managed Heaps
+
+Managed Heaps are the core of .NET's garbage-collected memory management. Objects created by managed code (e.g., via `new` in C#) are allocated on these heaps. The Garbage Collector (GC) periodically reclaims memory from unreachable objects, compacting the heaps to reduce fragmentation. Managed heaps are generational, dividing objects based on their lifetimes to optimize collection efficiency. The primary managed heaps include the Small Object Heap (SOH), Large Object Heap (LOH), Pinned Object Heap (POH), and Frozen Object Heap (FOH).
+
+### Small Object Heap (SOH)
+
+The Small Object Heap is designed for objects smaller than 85 KB. It is divided into three generations:
+
+- **Generation 0**: For newly allocated objects. Collections here are frequent and fast, targeting short-lived objects.
+- **Generation 1**: Acts as a buffer between Gen 0 and Gen 2. Objects surviving Gen 0 collections are promoted here.
+- **Generation 2**: For long-lived objects. Collections are less frequent but more expensive, involving the entire heap.
+
+The generational approach assumes most objects die young, allowing the GC to focus on smaller portions of the heap.
+
+### Large Object Heap (LOH)
+
+The Large Object Heap accommodates objects 85 KB or larger, such as large arrays or buffers. Unlike the SOH, the LOH is not compacted by default in workstation GC mode to avoid high CPU costs, though server GC mode supports compaction in .NET Framework 4.5+. Objects here are always considered Generation 2, and collections occur during full GCs. Fragmentation can be an issue, mitigated by techniques like object pooling.
+
+### Pinned Object Heap (POH)
+
+Introduced in .NET 5, the Pinned Object Heap is for objects that are pinned in memory (e.g., via `fixed` keyword or GCHandle). Pinning prevents the GC from moving objects during compaction, which is necessary for interop with unmanaged code. The POH segregates these objects to minimize fragmentation in other heaps, improving overall GC performance. Pinned objects are allocated here if the allocation requests pinning.
+
+### Frozen Object Heap (FOH)
+
+The Frozen Object Heap, available in .NET 8 and later, is optimized for immutable, long-lived objects that are never modified after creation. Examples include string literals or static readonly fields. Objects on the FOH are not subject to garbage collection once frozen, reducing GC overhead. This heap enhances performance in scenarios with many static or cached immutable data structures, as it allows the runtime to skip these during collections.
+
+## Conclusion
+
+Understanding the CLR's Loader Heaps and Managed Heaps is essential for .NET developers aiming to optimize memory usage and performance. By leveraging the specialized nature of these heaps, applications can achieve better scalability and efficiency. For deeper insights, consider profiling tools like dotnet-trace or Visual Studio's Performance Profiler to observe heap behavior in real-world scenarios.
+
+Whether you're debugging memory leaks or tuning GC settings, a solid grasp of these concepts will empower you to write more robust .NET code.