!address is a very powerful debugger command. It shows you exactly what your VM space looks like. If you already got the output from the !sos.eeheap -gc command (refer to this article for usage on sos), for example:
0:003> !eeheap -gcNumber of GC Heaps: 1generation 0 starts at 0x01245078generation 1 starts at 0x0124100cgeneration 2 starts at 0x01241000ephemeral segment allocation context: (0x0125a900, 0x0125b39c) segment begin allocated size001908c0 793fe120 7941d8a8 0x0001f788(128904)01240000 01241000 0125b39c 0x0001a39c(107420)Large object heap starts at 0x02241000 segment begin allocated size02240000 02241000 02243250 0x00002250(8784)Total Size 0x3bd74(245108)------------------------------GC Heap Size 0x3bd74(245108)
you can correlate the segments with the output of !address to get a better view of them. For this specific case here's the excerpt of the output from the !address command:
0:003> !address[omitted] 01232000 : 01232000 - 0000e000 Type 00000000 Protect 00000001 PAGE_NOACCESS State 00010000 MEM_FREE Usage RegionUsageFree 01240000 : 01240000 - 00052000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageIsVAD 01292000 - 00fae000 Type 00020000 MEM_PRIVATE Protect 00000000 State 00002000 MEM_RESERVE Usage RegionUsageIsVAD 02240000 - 00012000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageIsVAD 02252000 - 00fee000 Type 00020000 MEM_PRIVATE Protect 00000000 State 00002000 MEM_RESERVE Usage RegionUsageIsVAD 03240000 : 03240000 - 73050000 Type 00000000 Protect 00000001 PAGE_NOACCESS State 00010000 MEM_FREE Usage RegionUsageFree 76290000 : 76290000 - 00001000 Type 01000000 MEM_IMAGE Protect 00000002 PAGE_READONLY State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath C:\WINDOWS\system32\IMM32.DLL 76291000 - 00015000 Type 01000000 MEM_IMAGE Protect 00000020 PAGE_EXECUTE_READ State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath C:\WINDOWS\system32\IMM32.DLL[omitted] -------------------- Usage SUMMARY --------------------------[omitted]
-------------------- State SUMMARY -------------------------- TotSize Pct(Tots) Usage 0275c000 : 1.92% : MEM_COMMIT 7b20a000 : 96.20% : MEM_FREE 0268a000 : 1.88% : MEM_RESERVE
Largest free region: Base 03240000 - Size 73050000
This says that the 2 segments (starting from 01240000 and 02240000) are adjacent to each other - part of them are committed, the rest is still reserved memory. Before and after the 2 segments we got some free space there. As I mentioned below it’s very unlikely that the managed heap is fragmenting the VM because we are good about requesting large chunks at a time and usually the OS is not bad at giving us addresses that are pretty contiguous if possible. One of the very few cases where you would see managed heap fragmenting VM is if you have temporary large object segments and GC needs to frequently acquire and release VM chunks. Those chunks could be scattered in the VM space especially considering there are other things that consume VM as well at the same time.