Garbage Collection: Getting Rid of Our Objects

You've seen how to build and instantiate objects. You also need to know how to get rid of them when you no longer need them. In Visual Basic 6, when you had finished with an object, you had two means to free up memory it occupied. The lazy way was simply to wait for the object to go out of scope. The second and more professional way was to use SET myObject = Nothing.

Because Visual Basic 6 relied on COM, whenever a new instance of an object was created or a new reference to an existing object was set, an internal reference counter was incremented. When a reference to the object was released, the internal reference counter was decremented. When all references were released, the object was terminated and its memory and resources were released. At this point, the Class_Terminate event would fire predictably. We knew for sure when this event would happen and could place any cleanup code, such as code releasing connections to databases, in that event. This method of clearly terminating an object is known as deterministic finalization. Visual Basic 6 programmers always knew exactly when an object would be released.

The Stack and the Managed Heap

When you write a Visual Basic .NET program, the operating system allocates a chunk of memory exclusively for the program's use. The application has many different areas inside its own memory map that are used to store different objects. The program's memory has a code segment (the instructions that tell the computer what to do) and a data segment (in-memory objects, variables, and other temporary storage). The data segment is further broken up into the stack (value variables) and the heap (reference variables). Now you see why it's important to understand the difference between value and reference variables. The ways they are stored in memory and released when finished are different. A solid understanding of how reference variables are stored can materially help you increase the performance of your code. A depiction of a program's memory map is shown in Figure 4-8.

Figure 4-8

A program's memory map.

Value objects, such as integers, are stored on the stack. The stack is also used to hold data passed to functions and methods. As more items are placed on the stack, such as when you pass parameters to a procedure, the stack grows toward the heap. The compiler can determine the size of the stack because it knows the exact size of the value types used in procedures, function calls, and so on. As value variables go out of scope, they are immediately released and memory is freed up, shrinking the stack.

This is not the case with reference variables, which are placed on the managed heap. While we could use Set myObject = Nothing in Visual Basic 6 to release memory, Visual Basic .NET operates in a completely different way. In Visual Basic .NET, when an object goes out of scope it is internally flagged for deletion. At some later time, a low-level background thread examines heap memory to see what objects can safely be released. Now it's the system and not the programmer who must manage memory. This memory management is called nondeterministic finalization.

While setting an object to Nothing in Visual Basic 6 immediately releases memory, in Visual Basic .NET this process might take a while. In some cases, several minutes might elapse before the garbage collector (GC) will get around to releasing objects on the managed heap. The good news is that this delay typically provides a performance benefit. Rather than using CPU cycles to release objects that are no longer needed, the system usually waits until the application is idle, which decreases the impact on the user.

You can trigger garbage collection programmatically by calling System.GC.Collect, but this method is used only in rare circumstances when it is imperative to release many large objects immediately. Most programs will never make use of this.

The stack grows toward the heap (and vice versa). If they meet, that application has run out of memory, and once this happens it is just a matter of time before the application crashes. While crashes like these used to be a problem with complex programs, the .NET runtime uses advanced memory allocation algorithms to ensure it won't happen.