The garbage collector in .NET - Part 2: Compacting


If you are not familiar with the GC in .NET I wrote an article about that. It talkes about multiple generations and how the GC prefers to delete objects with a shorter lifetime than the ones with a longer one. This article explains you why the GC does that and what performance benefits you get from that.

The truth about the sweeping phase

I didn't tell you the whole process behind the sweeping phase. Deleting objects is the smaller part of what the GC does. There is a second process occurring after object got deleted. After that the GC compacts the heap.


Now let's have a look at the following situation: Your program has some stuff on the heap (some objects and lists and so on) and now the GC marked some of your objects for deletion. After he is done he will compact everything together.

Do you remember this relict of the past?


Yes the good old defragmentation tool. The behavior is kind of the same. The GC as well as the defragmentation tool move all the objects at the beginning. In older HDD drives it was faster to access the first files then to move the needle to the end of the drive. And it behaves a bit like that for the GC.

Why compacting?

There are multiple reasons. Just imagine you have a lot of super small holes in your memory and you try to create new objects which would be bigger than that hole? Well those small holes are then unusable. So you can get OutOfMemoryException even though there is enough (virtual) memory. Also your CPU cache plays a major role here. Especially small and short-lived objects, which are in a sequentiell block of memory, have a higher chance of getting cached. Sounds awesome, what the the GC does. But there is one last bit missing: the LOH.

Large Object Heap

As explained earlier compacting can take some time, but it is worth to do so ... unless your object is big enough. If your object is too big compacting it takes more time than you would gain from CPU caches and other stuff which benefits from compacting. The .NET team just benchmarked around and found 85kb is the magic threshold. If you have for example a List<int> with more than 21250 (85000/sizeof(int) = 21250) entries than this list would end up on the LOH. Even if you run GC.Collect the LOH will not be compacted. You have to pass a special flag called GCSettings.LargeObjectHeapCompactionMode to GC.Collect to make that work. At least until .net6 it behaves like that. Microsoft might change that behavior in the future.

Should I care?

Now the question for you is: Should I care?. And as always: It depends. For the majority of uses cases most likely not, even though it is nice to know. Also with 64bit processes the virtual space is much bigger so "holes" in the memory space are not so important anymore. Only if you work with large objects this information is crucial. Trivia: If you would create a List<int> with >21250 elements this would land on the LOH, but for example a LinkedList with >21250 elements would not. The reason is that the List is basically one array which grows and grows. The linked list is basically smaller nodes which are tiny. A practical implementation of that is the StringBuilder. The StringBuilder does not have one internal array, but multiple if the size of the current chunk gets bigger than 8kb.


Long story short, the LOH makes code run more efficient. At the cost of using available virtual memory address space less efficient. Compacting is a mechanism of the GC to have a more efficient memory management.


Buy Me a Coffee at
An error has occurred. This application may no longer respond until reloaded. Reload x