.NET Developers writing memory intensive applications would have seen several problems with Large Object Heap allocation and run into out-of-memory exceptions, even when the collective memory seems to be quite sufficient. .NET Framework 4.5 promises improvements in this area, with better LOH management and lesser fragmentation.
The CLR manages two separate heaps for allocation, the small object heap (SOH) and the large object heap (LOH). Any allocation equal to or greater than 85,000 bytes goes on the LOH. You can read more about the differences between the two heaps in these articles. Due to the performance tradeoffs in LOH, applications with large memory requirements such as heavy image processing face fragmentation and OutOfMemory Exceptions even before using the full memory limit.
There were already some improvements from .NET 3.5 to 4.0 in terms of total memory allocated. In one of the comments to the above issue, Brandon Bay, lead program manager for GC in .NET Framework, says –
Based on the example provided, we were able to allocate nearly 23 times as much memory before running out of memory on the large object heap going from version 3.5 to version 4.
and now .NET 4.5 seems to build on it –
In .NET 4.5, we made two improvements to the large object heap. First, we significantly improved the way the runtime manages the free list, thereby making more effective use of fragments. Now the memory allocator will revisit the memory fragments that earlier allocation couldn’t use. Second, when in server GC mode, the runtime balances LOH allocations between each heap. Prior to .NET 4.5, we only balanced the SOH. We’ve observed substantial improvements in some of our LOH allocation benchmarks as a result of both changes
You can read Brandon’s full post about more details. To learn more about how the .NET Framework’s Garbage Collector works, you can refer to the MSDN Documentation as well as this article by Andrew Hunter.