Re: Tracking a memory leak.
- From: "Alvin Bruney [MVP]" <some guy without an email address>
- Date: Mon, 14 May 2007 21:51:11 -0400
Nicholas:
Your assumption is that the initial sweep starts at the top most node in a
tree. There is nothing in the docs that I have found that indicates that
this is so. Perhaps you can point it out.
--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:eZBjmeWlHHA.1340@xxxxxxxxxxxxxxxxxxxxxxx
You don't need to write a short program.
If you have a tree where the nodes are only referenced by the parent,
and then the reference to the root is let go, then the whole tree is
eligible for collection.
Eligibility for GC doesn't matter if something is holding a reference
to an object or not, it's whether or not something is holding a reference
to that, and so on.
Basically, the CLR performs a mark and sweep, where it starts with the
stack on every thread (for the most part, there are other places it looks
which are not thread specific) and looks to see what references are held,
and then what references they hold, and so on, and so on. Once all of
those references are marked, anything else that is not marked is GC'ed.
So in this case, if you have a tree which has been let go, and nothing
is referencing it, or it's nodes, even though the parent references the
child nodes, the whole thing is eligible for GC.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"Alvin Bruney [MVP]" <some guy without an email address> wrote in message
news:uFnjOsVlHHA.4592@xxxxxxxxxxxxxxxxxxxxxxx
Yes, I see what you are saying. I don't know how trees work internally
either, however I suspect that they are linked lists of sorts. That would
mean that even though the root is null, the third node or n+1 still has a
bonafide root which is the node n. The second node does not have a root
as you correctly pointed out. Can this be collected?
I think it depends on which node is examined first. If the GC examines
node 0, a collection for the entire tree is possible, however for any
other node examined first, these have valid roots which won't be
collected.
The best way to resolve this is to write a short program that forces a
collection on a tree of length n and examine the heap - then we know for
sure. Any body got time on their hands?
--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
OWC Black book on Amazon and
www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1179032840.603566.217260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 12, 5:08 pm, "Alvin Bruney [MVP]" <some guy without an email
address> wrote:
of data. When I set the top object to null, I expect that the .NET
framework will clean up the memory at some point. However, I am
looking
Why do you expect this? A tree of n nodes where (n + n1 + n2 + n3...)
with n
set to null is still linked at n1 + n2 + n3...). These are valid roots
which
won't be garbage collected. I fully expect this to leak memory.
Alvin, perhaps I don't understand your post.
If I have a tree of objects, with a single root pointer pointing to
the root node, and that pointing to n other nodes, which in turn point
to n other nodes, etc, and I set the root pointer to null, then entire
tree becomes available for collection, even though parts of itself
refer to other parts.
Whether the GC bothers to collect it, and when, is a whole other
question.
Why do you think that a structure like this would "lead memory"?
.
- Follow-Ups:
- Re: Tracking a memory leak.
- From: Bruce Wood
- Re: Tracking a memory leak.
- From: Bill Butler
- Re: Tracking a memory leak.
- References:
- Tracking a memory leak.
- From: Frank Rizzo
- Re: Tracking a memory leak.
- From: Alvin Bruney [MVP]
- Re: Tracking a memory leak.
- From: Bruce Wood
- Re: Tracking a memory leak.
- From: Alvin Bruney [MVP]
- Re: Tracking a memory leak.
- From: Nicholas Paldino [.NET/C# MVP]
- Tracking a memory leak.
- Prev by Date: Re: Interesting behavior.
- Next by Date: Re: Print Document && Wrapping
- Previous by thread: Re: Tracking a memory leak.
- Next by thread: Re: Tracking a memory leak.
- Index(es):
Relevant Pages
|