Hi,
I recently started to use SOS to ananlyize memory dumps and got the
following at the end of the results from calling the !DumpHeap -Stat command.

Fragmented blocks larger than 0.5MB:
Addr Size Followed by
0x19010030 6.0MB large free object followed by 0x19607378
System.Net.NestedSingleAsyncResult
0x1515c9b4 20.0MB large free object followed by 0x16550060 System.DateTime

I'm not sure if the above means my heap is terribly fragmented or does it
mean i have some huge blocks of free memory that the GC will happily
allocate with new objects when it needs to.

Thanks,
-Chris

"Chris Mohan" <ChrisMohan (AT) discussions (DOT) microsoft.com> wrote

It means you have a 20MB free block starting at 0x1515c9b4 up to 0x16550060
and another 6MB free block starting at 0x19010030 up to 0x19607378

I'm not entirely sure this is the Large Object Heap, but it's quite strange
that you have System.DateTime on the LOH.

Willy.

Hi Willy,

Thanks for the response. I was aware the meaning you provided. My question
should have been more specific.

What i'm wondering: are these blocks of memory a problem?

The output of !Dumpheap states they are "Fragmented blocks".

If i take that statement literally it tells me: You've got a big problem
there are two big blocks of memory that the GC can't use to allocate new
objects into thier address spaces.

I'm afraid that's the correct interpretation, but part of me wonders if i'm
miss-reading things. Could it be that I don't have a problem and the GC can
use these blocks for allocating new objects into?

So, which if any interpretation is correct?

Re: The dateTime on the heap. I didn't write the code-- and its well... very
classic asp in style. Option Explicit is disabled as is option strict, i'm
pretty sure the datetime object is boxed on the heap. This code does things
like: Dim b as boolean = "True". That was my first optimization-- just
removing the quotes from all the boolean values so they wouldn't get
allocated as strings on the heap and then implicitly re-cast/unboxed as
boolean value types.

Thanks,
-Chris

"Willy Denoyette [MVP]" wrote:

No, these two blocks are not a problem, if you run !DumpHeap -Stat on a
system that has a badly fragmented heap ( hundreds of large free blocks)
,the output will look differently, that is, a warning message will be given
stating that your heap is badly fragmented, that happens only if you have
of free blocks, here you only have two large (>0.5Mb) free blocks, while you
have plenty of free contagious space available.

About the System.DateTime on the heap, I know that this type is on the heap,
but the question was are these blocks on the LOH or on the generational
heaps (Gen0, 1, 2).
You can inspect the addresses of the Generational heaps and compare them to
the addresses of the fragments. If the fragments are on the Gen2 heap, you
might have a problem when you are running the framework version v1.x. This
versions of the framework will never re-use the free space (6 MB and 20 MB)
to allocate other objects as long as they are sandwiched by two "fixed"
objects (pinned).




Willy.




"Chris Mohan" <ChrisMohan (AT) discussions (DOT) microsoft.com> wrote