Understanding the Garbage Collector

[MFRASER]

Ok. I have done some reading on the Garbage Collector, or
System.GC.Collect(). When I call this method does it only free up the
memory or does it also clear the Gen 0, Gen 1, Gen2 Collections. For some
reason when I call this in my program I do free up memory but the count on
the Gen 0 does not change.

Thanks

 

[MFRASER]

Except that I see the following. When I run my application it builds a Heap
to a size of 200+ meg, and when the heap is at this level the entire system
is at a crawl. When I execute the System.GC.Collect the memory drops back
to 30 meg and has a reasonable response time. If I do not execute the
System.GC.Collect the memory is never retrieved by the system. Based on
this it seams to me that the GC is not doing its job.

Thanks

 

[MFRASER]

I am using a profiler that keeps track of the heap size. I was incorrect in
my earlier statement about the Gen size, this actually was the count of
times the GC has collected the give level for example Gen 0 = 100 means that
the GC has collected Gen 0 100 times. Sorry for my confusion.

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Hi MFRASER,

It is possible that GC may not do its job correctly. For example if you have
small object that allocates huge amount of unmanaged memory GC won't kick
in. because from its point of view everything is ok. Hoever the memory is
not enough. When you call GC.Collect it might execute some finalizers, which
clear that unmanaged memory and from this point on everything goes smoothly
again.
You might don't know but some classes use internally unmanaged memory (AFAIK
Region nad MenuItem(?!?) are such classes)

In .NET 2.0 GC class introduces new method that lets us add some pressure to
the memory

 

[Chris Lyon [MSFT]]

Hi MFraser

Stoitcho is right. What you're probably seeing is unmanaged resources (the kind the GC has no control over) being released in objects' finalizers, which get run at some
undetermined time in the future. By calling GC.Collect, you're allowing the finalizers to get run at that point (although this is not always guaranteed), and as a result, resources are
being freed.

You have several options:
-ensure you are correctly implementing and using the Dispose Pattern (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpgenref/html/cpconfinalizedispose.asp). This will allowyou to free your resources deterministically.
-make sure you are not giving objects "mid-life crisis" (http://weblogs.asp.net/ricom/archive/2003/12/04/41281.aspx)
-using the Profiler is a good start, just make sure you're correctly interpreting the numbers

Hope that helps
-Chris

--------------------

From: "Stoitcho Goutsev \(100\) [C# MVP]" <[email protected]>
References: <#[email protected]> <[email protected]> <Ow$ysU8fEHA.2812 @tk2msftngp13.phx.gbl>
Subject: Re: Understanding the Garbage Collector
Date: Wed, 11 Aug 2004 15:54:00 -0400
Lines: 62
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Message-ID: <#[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
NNTP-Posting-Host: 207.219.70.165
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGXA03.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:265208
X-Tomcat-NG: microsoft.public.dotnet.languages.csharp

Hi MFRASER,

It is possible that GC may not do its job correctly. For example if you have
small object that allocates huge amount of unmanaged memory GC won't kick
in. because from its point of view everything is ok. Hoever the memory is
not enough. When you call GC.Collect it might execute some finalizers, which
clear that unmanaged memory and from this point on everything goes smoothly
again.
You might don't know but some classes use internally unmanaged memory (AFAIK
Region nad MenuItem(?!?) are such classes)

In .NET 2.0 GC class introduces new method that lets us add some pressure to
the memory

--
HTH
Stoitcho Goutsev (100) [C# MVP]

Except that I see the following. When I run my application it builds a Heap
to a size of 200+ meg, and when the heap is at this level the entire system
is at a crawl. When I execute the System.GC.Collect the memory drops back
to 30 meg and has a reasonable response time. If I do not execute the
System.GC.Collect the memory is never retrieved by the system. Based on
this it seams to me that the GC is not doing its job.

Thanks

that reference

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

 

[Evan Stone]

Stoitcho is right. What you're probably seeing is
unmanaged resources (the kind the GC has no control over)
being released in objects' finalizers, which get run at some
undetermined time in the future. By calling GC.Collect,
you're allowing the finalizers to get run at that point (although
this is not always guaranteed), and as a result, resources are
being freed.

....so is this a pretty good rule of thumb, implementing the Dispose
pattern when you're using un-managed resources, and conversely, letting
..NET's GC clean up automatically after managed objects, resources, etc.?

Thanks!

-Evan

 

[Chris Lyon [MSFT]]

That's exactly right. Just remember, the GC only cleans up memory, no resources.

-Chris

...so is this a pretty good rule of thumb, implementing the Dispose
pattern when you're using un-managed resources, and conversely, letting
.NET's GC clean up automatically after managed objects, resources, etc.?

Thanks!

-Evan

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.

 

[Evan Stone]

That's exactly right. Just remember, the GC only cleans up memory,
no > resources.

....so it's up to us to manage/release those resources responsibly.

-Evan

 

[Morten Wennevik]

Hi Evan,

The garbage collector will eventually release the resources itself, but it slows down the object destruction.

If you use Dispose, you might want to call GC.SuppressFinalize on that object, since Finalize is what garbage collector calls on the object when it is about to destroy it. And since Finalize is meant to release resources, calling Dispose removes the need to use it. GC.SuppressFinalize causes the garbage collector to not run Finalize thereby speeding up the destruction of the object.

 

[Chris Lyon [MSFT]]

Evan,

Yes, if you use unmanaged resources, you're responsible for proper (and timely) cleanup.

Morten,
The GC does not release resources, only memory. If an object implements code to release unmanaged resources in its finalizer (which all Framework classes should do, in case
Dispose is not called), then the GC will call the finalizer after the object has been collected. If there is no such cleanup code, then the resource will remain in memory until the
runtime shuts down

-Chris


--------------------

Hi Evan,

The garbage collector will eventually release the resources itself, but it slows down the object destruction.

If you use Dispose, you might want to call GC.SuppressFinalize on that object, since Finalize is what garbage collector calls on the object when it is about to destroy it. And since

Finalize is meant to release resources, calling Dispose removes the need to use it. GC.SuppressFinalize causes the garbage collector to not run Finalize thereby speeding up
the destruction of the object.

--

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.