Re: GC.Collect can be trusted?
- From: "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx>
- Date: Thu, 19 Apr 2007 22:38:17 +0200
"Ward Bekker" <wDotbekker@RemoveThisequanimityDotnl> wrote in message news:eSYj4tngHHA.5052@xxxxxxxxxxxxxxxxxxxxxxx
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.
.
- References:
- GC.Collect can be trusted?
- From: Ward Bekker
- Re: GC.Collect can be trusted?
- From: Christopher Ireland
- Re: GC.Collect can be trusted?
- From: Ward Bekker
- GC.Collect can be trusted?
- Prev by Date: Re: Making static class ToString() not possible, why?
- Next by Date: Re: delegate in custom attribute
- Previous by thread: Re: GC.Collect can be trusted?
- Next by thread: Re: GC.Collect can be trusted?
- Index(es):
Relevant Pages
|