{"id":1703,"date":"2013-10-02T00:00:00","date_gmt":"2013-10-02T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/large-object-heap-compaction-should-you-use-it\/"},"modified":"2021-05-17T18:36:05","modified_gmt":"2021-05-17T18:36:05","slug":"large-object-heap-compaction-should-you-use-it","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/large-object-heap-compaction-should-you-use-it\/","title":{"rendered":"Large Object Heap Compaction: Should You Use it?"},"content":{"rendered":"
\n

When we talk about heap memory in .NET it’s natural to picture the heap as a single large contiguous block of memory. However, given that it has been carefully architected in order to optimise performance, this isn’t quite true. Instead, .NET breaks down the heap into 4 separate chunks, the first three of which are known as the small object heaps (SOHs), and are referred to as generation 0, 1, and 2 respectively. We’ll be focusing on the fourth heap, which is known as the large object heap (LOH) and is used to store all objects that are larger than 85,000 bytes.<\/p>\n

.NET Memory in a Nutshell<\/h2>\n

If you’re already familiar with generational garbage collection, you can skip ahead to the next section, but if you’d like a primer \/ refresher than stay with me for a moment. The reason for segmenting memory in this manner is to reduce the performance cost of garbage collection. Empirical studies have shown that, for any realistic application, it tends to be the case that the objects that have been most recently created are the most likely to be destroyed, meaning that it’s advantageous to garbage collect recently allocated objects more often that the ones that have already been around for a while.<\/p>\n

By dividing the SOH into the 3 separate generations, it is possible for the garbage collector to collect only certain parts of the SOH (thus lowering the performance cost) rather than scanning everything each time a collection happens. In short, when a new object is instantiated onto the SOHs it is placed on generation 0. If it then survives a garbage collection it is ‘promoted’ to generation 1, and if it survives a second garbage collection it will be promoted to generation 2.<\/p>\n

\n

This is a slight simplification, some objects may remain in their current generation as they could be pinned, or added to the finalizer queue, or created during the garbage collection itself.<\/p>\n<\/p><\/div>\n

A generation 0 collection will happen when generation 0 is full, and a generation 1 collection will happen when generation 1 is full and will also collect generation 0. Similarly generation 2 collections also collect all lower generations, and thus is relatively expensive to do. Thankfully, the CLR tracks your application’s memory allocations at run time and continually tunes the size of the various generations for maximum performance, and also decides when to perform generation 2 collections. After a collection, any remaining objects on the SOHs are ‘compacted’, meaning they are shuffled up against each other to remove any gaps in memory. This means that the CLR can allocate only as much memory as is actually needed, rather than try and fit into new and promoted objects into awkwardly sized gaps (known as fragmentation).<\/p>\n

The LOH is also collected when a generation 2 collection happens, but unlike the small object heaps the large object heap isn’t compacted when it is garbage collected, which means that the LOH can get into a fragmented state. This is a problem because if the heap is sufficiently fragmented there will be no gaps large enough for new objects to be allocated into so new objects will have to be allocated at the end of the heap, thereby causing the heap to expand. If this process repeats continually the LOH will eventually consume all the system’s available memory and the program will crash with an OutOfMemory exception.<\/p>\n

For a more thorough understanding of .NET memory, check out this piece on the Top 5 .NET Memory management Fundamentals<\/a>.<\/p>\n

Why is LOH fragmentation so bad?<\/h3>\n

LOH fragmentation can be a difficult problem to tackle since. NET abstracts away the concept of physical memory locations. This makes it hard for the developer to figure out where the CLR may choose to allocate objects, and even harder to find out which particular allocation patterns are resulting in gaps being left in the LOH. To make troubleshooting harder, any potential problems tend to require the program to have been running for a length of time before becoming apparent, which makes debugging a tedious process.<\/p>\n

For more details on the dangers of LOH fragmentation, I recommend reading this excellent post by Andrew Hunter: “The dangers of the Large Object Heap<\/a>“. <\/p>\n

So what can you do to avoid LOH fragmentation?<\/h2>\n

Generally, solving LOH fragmentation problems requires following one of the three strategies:<\/p>\n