Memory consumption .NET 1.1 Where is the memory before a garbage collection?

[roger.dunham]

I am trying to identify whether a .NET 1.1 application that I have
written has a memory leak. I thought I understood how .NET memory
management worked, but it appears that there is more to it than I
realised.

I have created a simple app that creates a byte array which is stored
as a member of the application's main form.

The important code is shown below.

private byte[] m_ar; //byte array to store data

private void btnCreateArray_Click(object sender, System.EventArgs e)
{
int nSize = Convert.ToInt32( this.txtBufferSize.Text);
byte[] buffer = new byte[nSize];
m_ar = buffer;
this.Text = "Grabbed memory";
}

//set the member array to null to allow it to be garbage collected, //
then force a garbage collection.
private void btnReleaseArray_Click(object sender, System.EventArgs e)
{
m_ar = null;
System.GC.Collect();
this.Text = "Released memory";
}

//Force a garbage collection
private void btnCollectGarbage_Click(object sender, System.EventArgs
e)
{
GC.Collect();
}

The user enters a value into the text box txtBufferSize (A typical
test value is 50,000,000).

In Task Manager the amount of virtual memory used increases by about
50MB, which is exactly as you might expect.

However the amount of "Committed Bytes" as shown by the Performance
Monitor remains at a few 100K.

If I then force a garbage collection, then at that point, the number
of committed bytes increases to around 50MB. Task manager continues to
indicate that virtual memory is around 50MB.

My questions are:

Why does it take a garbage collection for the application to "commit"
the bytes?

Where is the memory that is being used before it appears as committed
bytes?

 

[Cowboy \(Gregory A. Beamer\)]

First thing to understand is you do not control GC, even if you code it in.
There are other factors that may delay GC even when you call it explicitly.

The memory footprint is part for your app and part for the underlying CLR
and libs you are running. People who come from the COM world often bitch
about this footprint without taking into account the COM libs loaded when
you boot up. That memory appears to be OS memory, so few people account for
it.

If you want a better peek into the GC download process explorer from
Sysinternals (now owned by MS). You can drill down into the process and see
the actual heaps. While this is not a perfect way to find memory leaks, a
huge amount of memory on Gen2 is an indication there might be a problem.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************

 

[roger.dunham]

Thanks for the message,

I appreciate at least some of the details of garbage collection, and I
do not normally write code that forces GC to occur.

What surprises me is that the 50MB allocated for the large byte array
only appears in the Performance Monitor as CLR Memory (actually as
memory in the large object heap) only AFTER I force a garbage
collection, although it is "shown" as allocated memory within Task
Manager. Is this a "quirk" of either the performance monitor or task
manager, or is the memory really being allocated somewhere else, and
gets "moved" to the Large Object Heap only when the garbage collection
occurs?

The main reason that I wish to know is that I am aware that the memory
usage shown by Task Manager is not very meaningful if memory is not in
short supply (http://getdotnetco.web119.discountasp.net/GdncStore/free/
Articles/The%20Memory%20Mystery.htm), and I am trying to find a more
meaningful measurement of the real memory usage.

Regards

Roger