As is the case with Java, a Microsoft .NET programmer will usually not take an interest in the operational details of garbage collection and can safely assume that unreferenced objects will be collected as required. This appendix, however, covers some of the features that are available when the default behavior of the garbage collector (GC) doesn’t meet the demands of an application; we expect the reader to be familiar with the principles of garbage collection.
The System.GC class provides methods to directly control the execution of the garbage collector. The garbage collector is designed to determine the best time to perform a collection; however, in some situations forcing a collection can improve performance, typically when the memory requirement of an application significantly decreases at a defined point in the code.
The static System.GC.Collect method is called to request a collection. The garbage collector will suspend active threads and compact the heap.
The CLR includes a performance enhancement known as generations. A generational collector—also known as an ephemeral collector—works on the following assumptions:
It’s faster to compact part of the heap than the whole heap.
The older an object is, the longer its lifetime will be.
New objects tend to be short lived, and groups of newly allocated objects tend to be accessed at the same time and have strong relationships.
Although these assumptions aren’t universally true, empirical testing has shown that they are valid for the majority of common business applications.
When an application starts, no objects are on the heap. As objects are allocated, they are considered to be in generation 0 (zero), which is the set of heap references that have yet to be examined by the garbage collector. When the collector runs, any objects that aren’t collected are promoted to generation 1 (one). New object allocations will be assigned to generation 0, and when the collector runs again, surviving generation 0 objects are promoted to generation 1 and generation 1 objects are promoted to generation 2. The CLR GC supports three generations (0, 1, and 2).
In normal operation, the GC will attempt a collection if there is insufficient memory in the heap to make a new object allocation. The generational approach allows the GC to attempt to satisfy an allocation request by reclaiming memory from the areas of the heap that are most likely to yield a return. Given the assumption that newly allocated objects tend to be short lived, it’s likely that a memory requirement can be satisfied by the references in generation 0. If the request cannot be satisfied, the GC can elect to move on to older generations, potentially minimizing the amount of time spent clearing the heap.
The GC class provides a method to allow explicit requests for generations to be collected. Calls to the GC.Collect(int) method will cause the indicated generation and all lesser generations to be collected, so a call to collect generation 1 will also cause collection of generation 0. The following GC methods determine which generation an object belongs to:
Int32 GetGeneration(Object obj) Int32 GetGeneration(WeakReference wr)
The WeakReference class in the second method is discussed in the Weak References section later in this appendix.
By default, the CLR assigns a separate thread for the Garbage Collector (GC), which allows the garbage collector to operate concurrently with application code. Disabling GC concurrency causes memory management to be performed using the same threads that execute the application code. The application will be less responsive, but the performance of GC tasks is greatly increased. Server-side applications typically benefit from disabling GC concurrency.
GC concurrency can be controlled by using the .NET application configuration file. For more details about configuration files and an example of disabling GC concurrency, see Appendix C.