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?
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:
!dumpheap -stat
Dump the method table of the Free object: !dumpheap -mt 000db8e8
Select one Free object from the list to examine more closely: !dumpobj 0x2003b0b0
Record the object's size
Dump the next object after it: !dumpobj 0x2003b0b0+1000
Find the object holding a reference !gcroot 0x2003b0b0+1000
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