Re: Tracking a memory leak.
- From: Bruce Wood <brucewood@xxxxxxxxxx>
- Date: 14 May 2007 21:38:52 -0700
No, he didn't make that assumption.
He correctly stated that the initial sweep doesn't start in the tree
at all. It starts on the _stack_ (and in other places mentioned by
Jeffrey Tan in his post). It then proceeds to follow all references
that fan out from that point. Any object not thus marked is eligible
for collection.
IF the root of the tree is referenced by a "live" object (that has
been found by starting from the stack, or a static object, or a
register, etc), then YES, the GC will follow the pointers from the
tree root to its child nodes, and their child nodes, and will traverse
the tree in some fashion, marking all of its nodes as ineligible for
collection.
If the only thing referenced by an object outside the tree is the
tree's root, AND you remove that reference, then no object in the tree
will be found during the mark phase, because nothing "live" points to
any part of the tree.
I think that the root of your misunderstanding (pardon the pun) is
that you seem to think that objects are garbage collected if they are
"marked for collection"... that is, you seem to be reasoning from the
angle that says that objects are collected if they are positively
marked. The opposite is true: objects are collected if they are _not
marked_ as "live". Mark-and-sweep finds everything that should _not_
be collected, then collects everything else.
On May 14, 6:51 pm, "Alvin Bruney [MVP]" <some guy without an email
address> wrote:
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 andwww.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"Nicholas Paldino [.NET/C# MVP]" <m...@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
messagenews: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]
- m...@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" <brucew...@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: Alvin Bruney [MVP]
- 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]
- Re: Tracking a memory leak.
- From: Alvin Bruney [MVP]
- Tracking a memory leak.
- Prev by Date: Re: best way to enumerate List<> & remove unwanted elements?
- Next by Date: Re: Interesting behavior.
- Previous by thread: Re: Tracking a memory leak.
- Next by thread: Re: Tracking a memory leak.
- Index(es):
Relevant Pages
|
