Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Large Object Heap Compaction, when is it good?

First off, how big is considered large? Is there anyway to determine how large an object is in heap?

.Net 4.5.1 comes with this LargeObjectHeapCompactionMode:

After the LargeObjectHeapCompactionMode property is set to GCLargeObjectHeapCompactionMode.CompactOnce, the next full blocking garbage collection (and compaction of the LOH) occurs at an indeterminate future time. You can compact the LOH immediately by using code like the following:

GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();      

From what I've heard, it's a bad thing to compact LOH! So, which one is worst? Compact LOH or having LOH fragmentation?

like image 743
Kamyar Nazeri Avatar asked Nov 17 '13 20:11

Kamyar Nazeri


People also ask

What is the large object heap?

If an object is greater than or equal to 85,000 bytes in size, it's considered a large object. This number was determined by performance tuning. When an object allocation request is for 85,000 or more bytes, the runtime allocates it on the large object heap.

What is small object heap?

Small Object Heap has generations that are checked from time to time. At the end of collection this heap is fragmented so it need to be compacte. If Large Objects were in this heep it would take long time for defragmentation.

What is pinned object heap?

What are Pinned Object Heaps in C#? A dedicated Pinned Object Memory, a fairly new type of managed heap segment, was added to the GC in . NET 5. (we have Small and Large Object Heaps so far). Pinning comes with its own set of drawbacks, as it causes fragmentation, and complicates object compaction a lot.


1 Answers

Allocations >= 85 KB go onto the LOH. Compacting the LOH is not bad -- it's just that LOH fragmentation isn't something the great majority of apps need to worry about, so for them it's not worth the expense of compacting.

Fragmentation occurs when you allocate several large objects and they all get taken from the same page of address space, then let some of those objects get collected. The remaining free space in that page might be unusable because it is too small, or even simply "forgotten" in the sense that the allocator won't ever reconsider using it again.

Eventually there are fewer and fewer clean pages to use, so the allocator will start to slow down as it forcibly moves objects or even start throwing OutOfMemory exceptions. Compaction moves those objects to new pages, reclaiming that free space.

Does your app have this object usage pattern? Most don't. And on 64-bit platforms, you might not even notice it as there's quite a bit more address space to fragment before it becomes a huge issue.

like image 169
Cory Nelson Avatar answered Oct 13 '22 05:10

Cory Nelson