Garbage Collection Explained Part 1

Over the past year I've heard many discussions about .NET's garbage collection, but not alot of explanation. I recently picked up "Programming Visual Basic .NET" from Microsoft Press, and in it was a very well presented explanation to the Garbage Collection mystery. I'd like to share with you the ideas presented from the book.

Before we talk Garbage Collection, we should start with an overview of what actually gets collected. There are two "super" data types in .NET: Reference types and Value types. Value types are generally numeric, while Reference types hold anything that is an object (which includes things like strings as well as more complex objects like DataSets and custom object we developers create).

A Value type is stored directly in memory. When you access your Integer variable, you're getting the value directly from where the variable is located.

A Reference type operates differently. When you create an object
Dim Object as New SomeObject
what you're really creating is a POINTER to that object. For instance, in the above example, there is an instance of SomeObject in memory. The Object variable we just declared merely POINTS to that SomeObject. Interestingly enough, if we did this:
Dim Object2 as SomeObject
Object2 = Object
Object2 now becomes a POINTER to the original SomeObject.

So to some up:Value types are stored directly, Reference types are merely pointers to the actual object.

Now that we have that under out belts, lets talk garbage collection. When you create a Reference type data type (which we'll just call "object"s from now on in this FAQ), the object gets added to a managed stack. As objects are created, the stack continues to be added to. Eventually however, the stack will get full. When this happens, Garbage Collection occurs.

A check is done (all behind the scenes) to see if any of the objects in the stack have variables activly pointing to them (called "roots"). If they do, they're flagged. Once all the objects have been checked, any non-flagged objects are dropped from the stack. The stack is compacted, and the resulting leftover memory is freed up to take new objects again.

And thats really how garbage collection works. Now, as developers, there are a few things we need to be mindful of:
1. Nondeterministic Finalization
I have an object A. I set all variables pointing to it to Nothing. I'm no longer using it, its ready to go. However, until the stack gets full to the point that a garbage collection occurs, my object will STILL BE ALIVE. By setting all variables pointing to my object to nothing, I've only logically destroyed it. It doesn't actully die until later on. For most objects, this won't mean anything. However, if you have objects that use unmanaged resources (i.e. you have an object that opens a file, or a database connection, etc.), you need to make extra care that all resources are released BEFORE the object is logically destroyed.

There are a few different ways to deal with the issue of Nondeterministic Finalization, and in Part 2 of this FAQ, I'll deal with those.

Thanks for reading, and if you have any questions or feedback please email me at jfrost10@shaw.ca

Thanks!

D'Arcy