The Garbage Collector (GC) does not perform reference counting. Some memory models maintain a reference count on components. When the count drops to zero, the object is removed from memory immediately. Overhead from reference counting, especially for objects that are never reclaimed, is considerable. There are two benefits to the reference counting model. First, the cost of garbage collection is distributed across the lifetime of the application. Second, it is proactive. Memory is reclaimed prior to being needed.

In managed code, an object graph is built when garbage collection is initiated, which avoids expensive reference counting. Objects without references in a tree are assumed to be collectable, and the memory for those objects is reclaimed. Memory then is consolidated and outstanding references are updated. This phase of memory management prevents future fragmentation of the managed heap. (We are ignoring finalization for the moment—we will cover this topic in the section "Finalization," later in this chapter.) The object graph is not cached between garbage collection cycles. Rebuilding the trees at each garbage collection cycle is one reason why garbage collection is expensive. However, garbage collection is performed only when needed, which is a considerable efficiency.

An object is rooted when another rooted object holds a direct or indirect reference to it. Rooted objects are not referenced by another object and reside at the base of an object graph. Rooted objects include static, global, and local objects. C# does not support global objects.

0:004> !dumpclass 00db21c4
Class Name: Store.Item
mdToken: 02000002 (C:storeStore.exe)
Parent Class: 790fa034
Module: 00d40c14
Method Table: 00d442dc
Vtable Slots: 5
Total Method Slots: 9
Class Attributes: 100001
NumInstanceFields: 3
NumStaticFields: 1
      MT    Field   Offset            Type   VT     Attr    Value Name
00d44224  4000001        8  System.Int32     0 instance           propProducts
790fe920  4000003        c  System.Int32     0 instance           propItemId
79129180  4000004        4  System.Single[]  0 instance           buffer
790fe920  4000002       24  System.Int32     0   static        3  nextPropId

The managed heap is organized into three generations and a large object heap. Generations are numbered 0, 1, and 2. New objects are placed in a generation or a large object heap. Younger and smaller objects are found in the earlier generations, whereas older and larger objects are found in the later generations and the large object heap. This is efficiency by proximity. Objects that are apt to communicate with other objects are kept close together in memory. This decreases page faults, which are costly, and decreases the amount of physical memory required at any time. Reducing page faults makes your application perform faster.

Garbage collection in .NET often is described as nondeterministic, which means that garbage collection is not called on demand. Garbage collection occurs automatically when memory allocation exceeds the memory reserved for a particular generation. When an application starts, Generation 0 is available for allocation. Eventually, the memory available to Generation 0 is exceeded, which triggers garbage collection on Generation 0 alone. This is more efficient because only a portion of the managed heap is experiencing garbage collection. If enough memory is reclaimed during garbage collection, the pending allocation is performed on Generation 0. If enough memory cannot be reclaimed, Generation 0 objects are promoted to Generation 1. This continues until Generations 0 and 1 are replete with objects. This time, garbage collection is performed on Generations 0 and 1. At that time, Generation 0 and Generation 1 objects are promoted to Generation 1 and Generation 2, respectively. By design, the older and larger objects tend to migrate toward the higher generations, whereas younger and smaller objects are found in lower generations.

Memory on the managed heap is allocated top-down. In Win32 applications, zero is at the bottom of the memory. Higher addresses are at the top of the memory space. New objects in managed code are allocated at higher addresses on the managed heap. The lower generations are at higher memory addresses. 256 kilobytes (KB), 2 megabytes (MB), and 10 MB are reserved for Generation 0, Generation 1, and Generation 2, respectively. These thresholds can be adjusted. The GC changes these thresholds based on the pattern of allocations in the managed application.

As the name implies, the large object heap hosts large objects (that is, objects greater than 85 KB). Instead of promoting these objects from one generation to another, which is costly, large objects are placed on the large object heap immediately at allocation.

Up to now we have ignored the finalization process. But it must be considered because it plays a vital role in garbage collection. Finalization affects the performance and effectiveness of garbage collection. In C#, finalization is linked to class destructors. For C++ programmers, .NET presents a different model for destructors.

Object.Finalize is the universal destructor in .NET. In C#, Finalize calls the class destructor. Destructors are called deterministically in C++. However, in C# the CLR calls destructors nondeterministically during garbage collection. You cannot invoke destructors directly. Destructors are called as part of the garbage collection process and are not called in a guaranteed sequence. In addition, you should clean up for only unmanaged resources in the destructor. Other managed objects might have been removed from memory already during garbage collection.

For deterministic garbage collection, implement the IDisposable interface and the Dispose method. You then can call the Dispose method directly.

Destructors add processing overhead to an object. The overhead is incurred even before the object is collected. The GC adds references for objects with destructors to the Finalization queue when the object is created. (This does not occur for objects without destructors.) Thus, the extra overhead starts at the beginning of the object’s lifetime.

Objects that have destructors but no outstanding references require at least two garbage collections to be reclaimed. During the first garbage collection cycle, references to collectable objects with destructors are transferred from the Finalization queue to the FReachable queue, which is serviced by a dedicated thread. These objects are added to the list of objects already waiting on the FReachable queue to have their destructors called. The Finalization thread is responsible for invoking destructors on objects and then removing that object from the FReachable queue. When that happens, the object can be reclaimed and deleted from memory at the next garbage collection.

The !finalizequeue command reports on objects, which are waiting to have their destructors called on the FReachable queue.

In Windows Vista, the Reliability and Performance Monitor is located in the Administrative Tools folder on the Control Panel. The Performance Monitor has several counters that are helpful when debugging managed applications. Table 16-9 itemizes some of the more useful memory-related counters. These counters are found in the .NET CLR Memory category.