views:

74

answers:

3

Hey all,

I think my question may be related to this question here but i'll ask it anyway!

If I have three objects: A, B and C where

A references B A references C B references C (and vice versa, cyclical)

will the B->C reference cause A to not be garbage collected when it might otherwise be collected?

+5  A: 

The answers on the question you've linked to explain it well. The garbage collector is designed to deal with objects that refer to each other in a cycle.

If your three objects refer to each other, and no other object refers to any of them, then the whole cycle is eligible for collection.

Tim Robinson
Minor nitpick: "the whole cycle *can* be collected at once" - i.e. they are all eligible for collection. There is no guarantee they all will be collected and destroyed in the same colleciton, especially if one has a destructor requiring it to be ressurected.
Rob Levine
A: 

As long as C does not reference A, then A will be garbage collected. The idea is, once all references to a particular object fall out of scope or are nulled/disposed, the GC kicks in. Thus, though A references C, if the reverse is not true, then C has no way of holding a handle to A.

Edit: Though I just read that you said they also reference each other vice-versa. In which case, it won't be GCed, like others mentioned here.

rakuo15
A: 

The GC will collect any object that is not referenced by a root object. Root objects are typically objects referenced by all appdomains (i.e. loaded assemblies/type objects), global and static object references, all object references on each thread's respective stack plus any object reference currently loaded into a CPU register.

At collection time, the GC walks the references of all known root objects and marks any object it finds along the way as "in use". When done, any objects not marked can be safely collected.

So if none of your objects are referenced (directly or indirectly) by a root object, it does not matter if there are cyclic references. They will all be eligible for collection regardless. I say eligible, because the GC uses three different strategies for collecting eligible objects, and for performance reasons only one of those collects all eligible objects when run.

Normally you won't have to think about this, it just works. But there is a lot more to garbage collection and you still need to understand the fundamentals of it in order to understand memory management and write bug free code that does not leak resources etc. Therefore its something every .NET developer should take a look at. Here are a few resources that explain more about how the CLR does garbage collection.

MSDN - Garbage Collector Basics and Performance Hints (Rico Mariani)

MSDN Magazine - Garbage Collection (Part 1): Automatic Memory Management in the Microsoft .NET Framework (Jeffrey Richter)

MSDN Magazine - Garbage Collection (Part 2): Automatic Memory Management in the Microsoft .NET Framework (Jeffrey Richter)

Mahol25