Is my heap fragmented

Question

0:000> !dumpheap -stat
total 1755874 objects
Statistics:
MT    Count    TotalSize Class Name
7b9b0c64        1           12 System.Windows.Forms.Layout.TableLayout+ColumnSpanComparer
....
7933303c    14006      4926456 System.Collections.Hashtable+bucket[]
65246e00      804      4982192 System.Data.RBTree`1+Node[[System.Int32, mscorlib]][]
054c55f0    44240      5662720 DevExpress.Utils.AppearanceObject
793040bc    98823      7613156 System.Object[]
793308ec   293700     55820016 System.String
002435f0    50315    138631888      Free
Total 1755874 objects

Fragmented blocks larger than 0.5 MB:
    Addr     Size      Followed by
15a195c8    0.8MB         15ae3950 System.Collections.ArrayList
15d81468    1.6MB         15f23708 System.String
15f23984    1.0MB         16029ae4 System.String
... about 7 more objects here
1ee51764    0.5MB         1eedbaa4 System.WeakReference
1f0df96c    2.4MB         1f34d4b0 System.String
1f3e1ca8    3.7MB         1f79afc4 System.WeakReference

I've been reading about pinning and fragmentation. Its looking fragmented to me given the massive amount of free space. I guess I have to now track it down.

Thoughts? feedback?

Demosthenes

Actually, having lots of free space is more like a sign of having no or little fragmentation. – Sicken

The output shows that the application has 50315 chucks of free memory and apparently most of them are less than half a megabyte. That looks fragmented to me. – Fianna

Answer 1

So...we know we have a fragmented heap. The next question is: what's causing the fragmentation? What's keeping these free objects from being released? The recommendations I have read is to examine the objects right after the free space:

1. !dumpheap -stat

2. Dump the method table of the Free object: !dumpheap -mt 000db8e8

3. Select one Free object from the list to examine more closely: !dumpobj 0x2003b0b0

4. Record the object's size

5. Dump the next object after it: !dumpobj 0x2003b0b0+1000

6. Find the object holding a reference !gcroot 0x2003b0b0+1000

7. Dump the gchandle of the object found.

I usually get down this rabbit hole, and my limited knowledge of the .NET API fails here. Is this the correct way to debug the problem?

Jeff

Ginger

I've had a look at which heap is fragmentation. I initially used !eeheap -gc to get a basis for the segments to search, however SOSEX (stevestechspot.com/SOSEXV2NowAvailable.aspx) has some commands just for this. Its looking like its in the Large object heap (which is expected as its never compacted) and to some degree in the gen2 heap. gen0 I don't care about and gen1 has no fragmentation. I think what your saying is try figure out the objects that are assigned after the fragmentation then work back from there to see whats causing the fragmentation, i.e. !dumpobj 0x2003b0b0+1000 – Demosthenes