Right, such statement could be much more accurate in 2011 🙂

Right, such statement could be much more accurate in 2011 🙂

Thanks guys.
@adamfurmanek:disqus indeed, I should rather use 85,000 bytes terminology. Sometimes forgetting we’re on Windows and with Microsoft, so using 1KB I should assume 1024 bytes 😉

Thanks Konrad.
Hmm, you’re probably right, it was not very clear for me. I’ve just verified in ‘Under the Hood of .NET Memory Management” which says “In fact, for performance reasons, .NET preferentially allocates large objects at the end of
the heap”. That’s probably because it’s quite on old book (2011), while LOH handling was optimized a lot in .NET 4.5.

However on the schemas presented on https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/large-object-heap it seems as you said, so:
1. Try to allocate in the free memory blocks
2. If no free memory chunks large enough found – try to allocate at the end of the heap (and request more segments from the OS if necessary)
3. If point 2. didn’t work – perform a full GC hoping that some more objects get reclaimed.

“garbage collector prefers to allocate new large objects at the end of the heap”

This is generally quite misleading – in fact GC always prefers to make use of fragmentation first.

Btw such arrays of doubles are allocated in LOH only in case of 32-bit framework, which is a small detail probably worth calling out.

> not 10626 elements as could be expected
Just nitpicking 🙂 I think it should be 10624, this gives 10624 * 8 doubles + 4 for sync block + 4 for type handle + 4 for size = 85004.