What causes memory fragmentation in .NET

Question

I am using Red Gates ANTS memory profiler to debug a memory leak. It keeps warning me that:

Memory Fragmentation may be causing .NET to reserver too much free memory.

or

Memory Fragmentation is affecting the size of the largest object that can be allocated

Because I have OCD, this problem must be resolved.

What are some standard coding practices that help avoid memory fragmentation. Can you defragment it through some .NET methods? Would it even help?

Solution 1

You know, I somewhat doubt the memory profiler here. The memory management system in .NET actually tries to defragment the heap for you by moving around memory (that's why you need to pin memory for it to be shared with an external DLL).

Large memory allocations taken over longer periods of time is prone to more fragmentation. While small ephemeral (short) memory requests are unlikely to cause fragmentation in .NET.

Here's also something worth thinking about. With the current GC of .NET, memory allocated close in time, is typically spaced close together in space. Which is the opposite of fragmentation. i.e. You should allocate memory the way you intend to access it.

Is it a managed code only or does it contains stuff like P/Invoke, unmanaged memory (Marshal.AllocHGlobal) or stuff like GCHandle.Alloc(obj, GCHandleType.Pinned)?

Solution 2

The GC heap treats large object allocations differently. It doesn't compact them, but instead just combines adjacent free blocks (like a traditional unmanaged memory store).

More info here: http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

So the best strategy with very large objects is to allocate them once and then hold on to them and reuse them.

Solution 3

The .NET Framework 4.5.1, has the ability to explicitly compact the large object heap (LOH) during garbage collection.

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

See more info in GCSettings.LargeObjectHeapCompactionMode

Comments

[supercat]

Out of curiosity, I wonder why LOH object sizes aren't rounded up to the next multiple of 4096? It would seem like that would facilitate compaction in some OS contexts (simply move virtual page pointers rather than copying memory), and would also greatly reduce fragmentation. Since LOH objects are generally a minimum of 85K, overhead from rounding up to 4K blocks would be 5% or less.

[Tim Robinson]

The GC doesn't compact the large object heap, which is where objects > 85KB live. Once the LOH is fragmented, there's no way to defragment it.

[Dave Black]

As of .NET 4.5.1m there is a way to compact the LOH manually though I would strongly recommend against it for the reason that it is a huge performance hit for your app. blogs.msdn.microsoft.com/mariohewardt/2013/06/26/… (again, I recommend against it)

[Dave Black]

I would strongly recommend against it for the reason that it is a huge performance hit for your app for 2 reasons: 1. it is time consuming 2. it clears any of the allocation pattern algorithm that the GC has collected over the lifetime of your app. While your app is running, the GC actually tunes itself by learning how your app allocates memory. As such, it becomes more efficient (to a certain point) the longer your app runs. When you execute GC.Collect() (or any overload of it), it clears all of the data the GC has learned - so it must start over.

[23W]

@Dave Black, where you found such info? MSDN doesn't contain info about impact of LOH compacting on allocation pattern algorithm.

[mbadawi23]

@supercat, that comment is worth to be in its own question. If you know the answer by now, please let me know.

[supercat]

@mbadawi23: At least in .NET 2.0, the LOH would get used for some objects that aren't very big. For example, I think any double[] over 1,000 elements would get forced into the LOH. Allocating a double[1024] as three 4096-byte chunks would be rather wasteful. Of course, my real suspicion is that allocating a double[1024] wasn't really a good idea anyway.