GC.Collect can be trusted?

[Ward Bekker]

Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn't found it necessary to collect the object,
even when asked explicitly.

Regards,

Ward

[DeveloperX]

On 19 Apr, 11:37, Ward Bekker <wDotbekker@Rem oveThisequanimi tyDotnl>
wrote:

Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn't found it necessary to collect the object,
even when asked explicitly.

Regards,

Ward

I believe it attempts to reclaim all objects. If you've got a memory
leak though you might want to take a look at the CLR profiler

http://www.microsoft.com/downloads/d...displaylang=en

thats for 1.1, there's a link for 2.0 at the bottom..

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Ward,
Using GC.Collect to attempt to identify memory leaks is not a realistic
solution. Memory Leaks are generally caused by developers. Especially when
they fail to dispose of objects that need to be disposed, or if they fail to
implement similar patterns on their own objects where necessary.
There are a number of memory profilers you can use to track down this type
of issue. As well, FXCop can help you to identify bad coding patterns.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Ward Bekker" wrote:

Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn't found it necessary to collect the object,
even when asked explicitly.

Regards,

Ward

[Ward Bekker]

Let me explain a bit more. I am using a memory profiler, and see several
live objects that should be collected at the time I created a memory
snapshot.

I need to be sure that they are _really_ live objects because of a
mistake in our own code, or that they just alive because the GC.Collect
can't be trusted.
Peter Bromberg [C# MVP] wrote:

Ward,
Using GC.Collect to attempt to identify memory leaks is not a realistic
solution. Memory Leaks are generally caused by developers. Especially when
they fail to dispose of objects that need to be disposed, or if they fail to
implement similar patterns on their own objects where necessary.
There are a number of memory profilers you can use to track down this type
of issue. As well, FXCop can help you to identify bad coding patterns.
Peter

[Christopher Ireland]

Ward Bekker wrote:

Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

I think you will find the following article useful and interesting:
http://support.microsoft.com/kb/318263/en-us

"Because of the garbage collection package that is implemented in the
Microsoft .NET Framework, it is not possible to have a memory leak in
managed code. This suggests two questions: How then can a memory leak occur?
Why does it appear that you have a memory leak?"

--
Thank you,

Christopher Ireland

[Ward Bekker]

Hi Cristopher,

My definition of a memory leak for managed frameworks:

All objects that should be garbage collected, but can't because they are
still referenced by other objects that will not be garbage collected ;-)

Christopher Ireland wrote:

Ward Bekker wrote:

>Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

I think you will find the following article useful and interesting:
http://support.microsoft.com/kb/318263/en-us

"Because of the garbage collection package that is implemented in the
Microsoft .NET Framework, it is not possible to have a memory leak in
managed code. This suggests two questions: How then can a memory leak
occur? Why does it appear that you have a memory leak?"

[Christopher Ireland]

Ward Bekker wrote:

My definition of a memory leak for managed frameworks:

All objects that should be garbage collected, but can't because they
are still referenced by other objects that will not be garbage
collected ;-)

The article I quoted suggests to me that there are no managed objects that
can't be garbage collected!

--
Thank you,

Christopher Ireland

[Christof Nordiek]

"Christophe r Ireland" <ci******@gmail .comschrieb im Newsbeitrag
news:3B******** *************** ***********@mic rosoft.com...

"Because of the garbage collection package that is implemented in the
Microsoft .NET Framework, it is not possible to have a memory leak in
managed code. This suggests two questions: How then can a memory leak
occur? Why does it appear that you have a memory leak?"

Though garbage collection is very usefull to provent memory leaks, this
quote is a bit to optimistic. Sure ther can be memory leaks in managed code.
E.g. all static fields aren't collected. So any object directly or
indirectly referenced by a static field wouldn't be collected. Also any
variables very high in the call stack can prevent referenced object from
being collected, (though the lifetime of a variable can be shortened by the
compiler.)
By this a memory leak in managed code can easily construckted.

But it's very unlikely to happen in real code. And it's much 'harder' to do
it purposelessly in managed code, than in unmanaged colde.

Regards
Christof

[Christopher Ireland]

Christof Nordiek wrote:

Though garbage collection is very usefull to provent memory leaks,
this quote is a bit to optimistic. Sure ther can be memory leaks in
managed code. E.g. all static fields aren't collected. So any object
directly or indirectly referenced by a static field wouldn't be
collected. Also any variables very high in the call stack can prevent
referenced object from being collected, (though the lifetime of a
variable can be shortened by the compiler.)
By this a memory leak in managed code can easily construckted.

Interesting. Are you suggesting that the Microsoft Article 318263 I posted a
link to is somehow incorrect or misleading? Do you have any Microsoft links
which specifically refer to memory leaks in managed code?

This is an important area for me to clear up with my clients and I would
appreciate being able to quote Microsoft sources.

--
Thank you,

Christopher Ireland

[Nicholas Paldino [.NET/C# MVP]]

Ward,

That's the thing though, if the object that you think should be garbage
collected is referenced by another object which is rooted (meaning you are
holding onto it some other way) and so on, then your object should NOT be
garbage collected. This is well-defined behavior for GC systems.

If you feel that your object should be collected at any time, then what
you really want are weak references. Take a look at the WeakReference
class.

Also, remember, if you have a delegate that points to a method on an
instance, then that instance is not eligible for GC. So if you subscribed
to an event, and didn't unsubscribe, then that instance is going to live on
as long as the object that publishes the event lives. A lot of developers
forget about this.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m
"Ward Bekker" <wDotbekker@Rem oveThisequanimi tyDotnlwrote in message
news:eS******** ******@TK2MSFTN GP05.phx.gbl...

Hi Cristopher,

My definition of a memory leak for managed frameworks:

All objects that should be garbage collected, but can't because they are
still referenced by other objects that will not be garbage collected ;-)

Christopher Ireland wrote:

>Ward Bekker wrote:

>>Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

I think you will find the following article useful and interesting:
http://support.microsoft.com/kb/318263/en-us

"Because of the garbage collection package that is implemented in the
Microsoft .NET Framework, it is not possible to have a memory leak in
managed code. This suggests two questions: How then can a memory leak
occur? Why does it appear that you have a memory leak?"