Programming Visual Basic .NET

Memory Management and Garbage Collection

In any object-oriented programming environment, there arises the need to instantiate and destroy objects. Instantiated objects occupy memory. When objects are no longer in use, the memory they occupy should be reclaimed for use by other objects. Recognizing when objects are no longer being used is called lifetime management , which is not a trivial problem. The solution the CLR uses has implications for the design and use of the components you write, so it is worth understanding.

In the COM world, the client of an object notified the object whenever a new object reference was passed to another client. Conversely, when any client of an object was finished with it, the client notified the object of that fact. The object kept track of how many clients had references to it. When that count dropped to zero, the object was free to delete itself (that is, give its memory back to the memory heap). This method of lifetime management is known as reference counting . Visual Basic programmers were not necessarily aware of this mechanism because the Visual Basic compiler automatically generated the low-level code to perform this housekeeping. C++ developers had no such luxury.

Reference counting has some drawbacks:

• A method call is required every time an object reference is copied from one variable to another and every time an object reference is overwritten.

• Difficult-to-track bugs can be introduced if the reference-counting rules are not precisely ...