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

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

If they *are* saying that, then I disagree - it's easy to assign
something to a static variable and forget about it. You'll then
potentially have what looks like a memory leak, and it would certainly
be due to a bug in your code. Not a failure to call free(), but a
failure to effectively make the object eligible for garbage
collection.

I agree. It's a question of how terminology is understood. I understand that
in an environment where memory is managed, like the .NET Framework, then
memory which is not released when the application terminates is memory that
has failed to be effectively managed by the said environment.

Managed memory which accumulates while the application is running is not
what I would understand as a memory leak (the memory hasn't "leaked" out of
control of the application) but certainly looks like one and is due, as you
say, to not making the relevant objects eligible for garbage collection.

--
Thank you,

Christopher Ireland

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

No, it doesn't mean a bug in the GC. It almost certainly means a bug
in Ward's code, where he's got a reference to an object even though
his design (or whatever) says that he shouldn't. I believe he's
trying to track down that bug. Read Peter's sentence very carefully:

<quote>
He's talking about objects to which he still has references, but
*shouldn't*, and so they stay allocated even though they should have
been released.
</quote>

You're right, I hadn't read the sentence as carefully as I should have done
and yes, re-reading it makes it clear that the bug is not in the GC.

--
Thank you,

Christopher Ireland

"Peace comes from within. Do not seek it without."
Siddhartha Gautama

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

Certainly a *user* couldn't care less whether their memory is being
eaten due to references that are still available or due to memory
which no code knows about - and it doesn't make huge odds when it
comes to debugging, either.

No, but it does make a difference to whether or not you can effect a change
in how the memory is being used. If the memory is being used by references
that are still available then you can change it, if it due to a bug in the
GC then you can't. In an unmanaged environment you are completely
responsible for memory management and can therefore always effect a change,
AFAIK.

--
Thank you,

Christopher Ireland

[Jon Skeet [C# MVP]]

Christopher Ireland <ci******@gmail .comwrote:

Jon Skeet [C# MVP] wrote:

Certainly a *user* couldn't care less whether their memory is being
eaten due to references that are still available or due to memory
which no code knows about - and it doesn't make huge odds when it
comes to debugging, either.

No, but it does make a difference to whether or not you can effect a change
in how the memory is being used. If the memory is being used by references
that are still available then you can change it, if it due to a bug in the
GC then you can't. In an unmanaged environment you are completely
responsible for memory management and can therefore always effect a change,
AFAIK.

No, in neither case are you completely responsible.

Very, *very* few unmanaged Windows programs don't use either third
party libraries or Win32 calls. I view a memory leak in the GC as being
comparable to a memory leak in those third party libraries or Win32
calls - basically, you have a problem which is hard to deal with in
either case.

Likewise, in both managed code and unmanaged code, memory leaks are
more *likely* to be due to bugs in your own code.

The tools you might use to track down such problems will clearly be
different, but both kinds of leak are definitely possible in both
situations.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

No, in neither case are you completely responsible.

One is always completely responsible for one's code and it was never my
intention to suggest otherwise. What I'm saying is that in a managed memory
environment you are not responsible for the direct allocation and
deallocation of memory and therefore have to rely on an intermediate layer
that is. What this means is that there are instances in the running of a
program where an object is not in scope and where a programmer cannot
directly destroy it, giving rise to this object "unnecessar ily" occupying
memory and therefore the appearance of a memory leak.

Very, *very* few unmanaged Windows programs don't use either third
party libraries or Win32 calls. I view a memory leak in the GC as
being comparable to a memory leak in those third party libraries or
Win32 calls - basically, you have a problem which is hard to deal
with in either case.

Likewise, in both managed code and unmanaged code, memory leaks are
more *likely* to be due to bugs in your own code.

I think I've been mistaken in overly referring to bugs in the GC and I agree
with you that this is by far the least likely scenario.

The tools you might use to track down such problems will clearly be
different, but both kinds of leak are definitely possible in both
situations.

Yes, the question is: once you know which object is unnecessarily occupying
space, can you guarantee its destruction before the program terminates? I
think this is the question that Ward is going to be asking himself once he's
tracked his object down.

--
Thank you,

Christopher Ireland

[Jon Skeet [C# MVP]]

Christopher Ireland <ci******@gmail .comwrote:

Jon Skeet [C# MVP] wrote:

No, in neither case are you completely responsible.

One is always completely responsible for one's code and it was never my
intention to suggest otherwise. What I'm saying is that in a managed memory
environment you are not responsible for the direct allocation and
deallocation of memory and therefore have to rely on an intermediate layer
that is. What this means is that there are instances in the running of a
program where an object is not in scope and where a programmer cannot
directly destroy it, giving rise to this object "unnecessar ily" occupying
memory and therefore the appearance of a memory leak.

Indeed. My point was that even in the unmanaged world, while you will
be directly responsible for *some* (quite possibly most) of the memory
allocation, you're unlikely to be responsible for *all* of it.

Even if you're calling malloc()/free(), that's still going through an
intermediate layer. I believe free() in Windows had a subtle and rare
bug at some point, for instance...

<snip>

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"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 ;-)

Objects that are still referenced should not be GC, that would be a serious bug if the GC
collected such objects ;-)
The problem you are describing is not a real "memory leak", the problem is that you don't
know who's keeping a reference to the object, so you aren't able to release the object by
setting it's reference to null, this is an application bug disguised as a leak.
A "real leak " is part of the memory, occupied by a "non referenced object" staying
allocated on the GC heap after a GC run, if the GC can't deallocate the memory it will stay
in the heap until the process terminates, no-one is still under control of this chunk of
memory. Or otherwise, a leak in the managed heap is the result of a CLR bug, possibly a GC
bug.

Willy.

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

Indeed. My point was that even in the unmanaged world, while you will
be directly responsible for *some* (quite possibly most) of the memory
allocation, you're unlikely to be responsible for *all* of it.

Even if you're calling malloc()/free(), that's still going through an
intermediate layer. I believe free() in Windows had a subtle and rare
bug at some point, for instance...

Sure, although I think there is a fundamental qualitative and quantitive
difference between the intermediate layer that effects memory in unmanaged
applications and in managed applications. Non-deterministic memory
management by its very nature means that programmers cannot make completely
predictable changes to memory allocation through it.

--
Thank you,

Christopher Ireland

[Ward Bekker]

Hehe, my question caused quite some discussion. Thank you for your help!

Let me try to clarify a bit more:

1. I'm hunting for bugs in my own code, specifically for object graphs
that are still connected to the root object but are not needed any more.
These objects are correctly not garbage collected because the code did
not dereference them. I use among others Ants Profiler to look what
objects are still in memory and alive.

2. I want to make sure that all objects that can be garbage collected (
disconnected from the root object) _are_ not longer alive. The
documentation is not very clear that GC.Collect will actually throw out
the thrash.

Jon Skeet maybe explains it better what I'm trying to do: See
news://news.microsoft.com:119/11****...oglegroups.com

Besides Jon's suggestion, I also found this method:
GC.GetTotalMemo ry(true).

According to the documentation, the true argument tells to wait for the
garbage collection to finish before returning so the result will be more
accurate. I noticed a delay when there really was stuff to collect when
executing.

Maybe I should do both ways, just to make sure ;-)

Thank you very much,

Ward

[mpetrotta]

On Apr 20, 4:59 am, Ward Bekker <wDotbekker@Rem oveThisequanimi tyDotnl>
wrote:

2. I want to make sure that all objects that can be garbage collected (
disconnected from the root object) _are_ not longer alive. The
documentation is not very clear that GC.Collect will actually throw out
the thrash.

Seems pretty clear to me, if lacking in detail:
"However, the Collect method does not guarantee that all inaccessible
memory is reclaimed."

Michael