Big compaction of the heap of an object, when is it good?

Question

First, how big is considered big? Is there a way to determine how large the object is on the heap?

.Net 4.5.1 comes with this LargeObjectHeapCompactionMode :

After the LargeObjectHeapCompactionMode property is set to GCLargeObjectHeapCompactionMode.CompactOnce, the next complete blocking of garbage collection (and LOH densification) occurs for an indefinite future time. You can immediately compress LOH using the following code:

 GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce; 

From what I heard, this is a bad thing for compact LOH! So which is the worst? Compact LOH or fragmented LOH?

Answer 1

Allocation> = 85K goes to LOH. LOH compaction is not bad - it’s just that LOH fragmentation is not more than most applications need, so it’s not worth the cost of compaction.

Fragmentation occurs when you select several large objects, and they all come from the same page of the address space, and then skip some of these objects. The remaining free space on this page may not be suitable, because it is too small or even simply “forgotten” in the sense that the distributor will no longer review its use.

Ultimately, there are fewer and fewer blank pages, so the allocator will start to slow down as it forces objects to move or even starts throwing OutOfMemory exceptions. Compaction moves these objects to new pages, freeing up this free space.

Does your application have this pattern for using an object? Most are not. And on 64-bit platforms, you may not even notice it, since there is quite a lot of address space for fragmentation, before it becomes a huge problem.