LOH (Large Object Heap) contains objects that are 85,000 bytes or bigger (there\u2019s also some objects that are less than 85,000 bytes that are allocated on the LOH by the runtime itself but usually they are very small and we\u2019ll ignore them for this discussion). <\/FONT><\/P>\n <\/FONT> <\/P>\n The way LOH is implemented changed dramatically from 1.0 to 1.1. In 1.0 we used a malloc type of allocator for allocating large objects; in 1.1 and beyond we use the same allocator for both large and small objects: we acquire memory from the OS by heap segments and commit on a segment as needed. There\u2019s very little difference between 1.1 and 2.0 for LOH. <\/FONT><\/P>\n <\/FONT> <\/P>\n LOH is not compacted \u2013 however if you want a large object to be pinned you should make sure to pin it because whether LOH is compacted or not is an implementation detail that could be changed in the future. Free blocks between live large objects are threaded into a free list which will be used to satisfy large object allocation requests. Note that this is a real advantage for managed heap \u2013 we are able to be very efficient to manage fragmentation because we can coalesce adjacent free objects into a big free block. If a free block is too large we call MEM_RESET on it to tell the OS to not bother backing it up. So far I haven\u2019t heard of any fragmentation problems from production code (of course you write a program that specifically fragments the LOH) \u2013 I think one reason is we are doing a good job controlling fragmentation; the other reason is people usually don\u2019t churn LOH too much \u2013 one typical pattern I\u2019ve seen people use LOH is to allocate some large arrays that hold on to small objects. <\/FONT><\/P>\n <\/FONT> <\/P>\n