This section is an overview of garbage collection. A detailed explanation of the mechanics of garbage collection is presented in Chapter 16. Two assumptions guide the implementation of garbage collection in the managed environment. The first assumption is that objects are more likely to communicate with other objects of a similar size. The second assumption is that smaller objects are short-lived objects, whereas larger objects are long-lived objects. For these reasons, the GC attempts to organize objects based on size and age.

In the managed environment, garbage collection is nondeterministic. With the exception of the GC.Collect method, whose use is discouraged, developers cannot explicitly initiate garbage collection. The managed heap is segmented into Generations 0, 1, and 2. The initial sizes of the generations are about 256 kilobytes (KB), 2 megabytes (MB), and 10 MB, respectively. As the application executes, the GC fine-tunes the thresholds based on the pattern of memory allocations. Garbage collection is prompted when the threshold for Generation 0 is exceeded. At that time, objects that can be discarded are removed from memory. Objects that survive garbage collection are promoted from Generation 0 to 1. The generations then are compacted and references are updated. If Generation 0 and Generation 1 exceed their thresholds during garbage collection, both generations are collected. Surviving objects are promoted from Generation 1 to Generation 2 and from Generation 0 to Generation 1. In fewer instances, all three generations will exceed thresholds and require collection. The later generations typically contain larger objects, which live longer. Because the short-lived objects reside primarily on Generation 0, most garbage collection is focused in this generation. Generations allow garbage collection to implement a partial cleanup of the managed heap at a substantial performance benefit.

Objects larger than 85 KB are considered large, and they are treated differently from other objects. Large objects are placed on the large object heap, not in a generation. Large objects are generally long-lived components. Placing large objects on the large object heap eliminates the need to promote these objects between generations, thereby conserving resources and reducing the number of overall collection cycles. The large object heap is collected with Generation 2, so large objects are collected only during a full garbage-collection cycle.

When garbage collection is performed, the GC builds a graph of live objects, called an object graph, to determine which objects are not rooted and can be discarded. First the GC populates the object graph with root references. The root references of an application are global, static, and local references. Local references include references that are function variables and parameters. The GC then adds to the graph those objects reachable from a root reference. An embedded object of a local is an example of an object reachable from a root reference. Of course, the embedded object could contain other objects. The GC extrapolates all the reachable objects to compose the branches of the object graph. Objects can appear only once in the object graph, which avoids circular references and related problems. Objects not in the graph are not rooted and are considered candidates for garbage collection.

Objects that are not rooted can hold outstanding references to other objects. In this circumstance, the object and the objects that it references potentially can be collected. (See Figure 17-1.)

Figure 17-1. Rooted and nonrooted objects

The Rooted application demonstrates how non-rooted objects are collected. In the application, the Branch class contains the Leaf class, which contains the Leaf2 class. In the Form1 class, an instance of the Branch class is defined as a field. When an instance of the Branch class is created, it is rooted through the Form1 instance. Leaf and Leaf2 instances are rooted through the Branch field. (See Figure 17-2.)

Figure 17-2. An object graph of the Rooted application

In the following code, a modal message box is displayed in the finalizer. This is done here for demonstration purposes only—it generally is considered bad practice:

public class Branch {
    ~Branch() {
        MessageBox.Show("Branch destructor");
    }
    public Leaf e = new Leaf();
}


public class Leaf {
    ~Leaf() {
        MessageBox.Show("Leaf destructor");
    }
    public Leaf2 e2 = new Leaf2();
}


public class Leaf2 {
    ~Leaf2() {
        MessageBox.Show("Leaf2 destructor");
    }
}

The user interface of the Rooted application allows users to create the Branch, which includes Leaf instances. (See Figure 17-3.) You then can set the Branch or any specific Leaf to null, which interrupts the path to the root object. That nullified object is collectable. Objects that are rooted through the nullified object are also now collectable in this application. For example, if the Leaf instance is set to null, the Branch instance is not collectable; it is before the Leaf reference in the object graph. However, any Leaf2 object belonging to the Leaf is immediately a candidate for collection. After setting the Branch or Leaf objects to null, garbage collection can occur. If it doesn’t occur, click the Collect Memory button in the application to force garbage collection.

Figure 17-3. The Rooted application

As mentioned, garbage collection occurs when the memory threshold of Generation 0 is exceeded. Other events, which are described in the following list, can prompt garbage collection:

Certain suppositions are made for garbage collection in the managed environment. For example, small objects are generally short-lived. Coding contrary to these assumptions can be costly. Although it makes for an interesting theoretical experiment, this is not recommended for production applications. Defining a basket of short-lived but larger objects is an example of coding against assumptions of managed garbage collection, which would force frequent and full collections. Full collections are particularly expensive. Defining a collection of near-large objects—objects that are slightly less than 85 KB—is another example. These objects would apply immediate and significant memory pressure. Because they are probably long-lived, you have the overhead of eventually promoting the near-large objects to Generation 2. It would be more efficient to pad the near-large objects with a buffer, forcing them into large object status, in which the objects are directly placed onto the large object heap. You must remain cognizant of the underlying principle of garbage collection: Implement policies that enhance, rather than exacerbate, garbage collection in the managed environment.

One such policy is to limit boxing. Constant boxing of value types can trigger more frequent garbage collection. Boxing creates a copy of the value type on the managed heap. Most value types are small, and the resulting object placed on the managed heap is larger than the original value. This is yet another reason that boxing is inefficient and should be avoided when possible. This is particularly a problem with collection types. The best solution is to use generic types as described in Chapter 7.

Finalization is discussed in complete detail in the section titled "Finalizers" later in this chapter.

There are two flavors of garbage collection: Workstation GC is optimized for a workstation or single-processor system, whereas Server GC is fine-tuned for a server machine that has multiple processors. Workstation GC is the default; Server GC is never the default—even with a multiprocessor system. Server GC can be enabled in the application configuration file. If your application is hosted by a server application, that application might be preconfigured for Server GC. Your application then will execute with Server GC.

Workstation GC can have concurrent garbage collection enabled or disabled. Concurrent is a single thread concurrently servicing the user interface and garbage collection. The thread simultaneously responds to events of the user interface while also handling garbage collection responsibilities. The alternative is non-concurrent. When garbage collection is performed, other responsibilities, such as servicing the user interface, are deferred.

<configuration>
    <runtime>
        <gcConcurrent enabled="false"/>
    </runtime>
</configuration>

<configuration>
    <runtime>
        <gcServer enabled="true"/>
    </runtime>
</configuration>