The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the newoperator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.
This section describes how the garbage collector automatically manages the allocation and release of memory for the managed objects in your application. In addition, it describes the recommended design pattern to use to properly clean up any unmanaged resources that your application creates.
.gif) Note: |
|---|
In the .NET Framework version 1.0, the common language runtime (CLR) has a separate memory manager for the large object heap. Under some circumstances this memory manager does not return unused memory to the operating system, and in a few cases it does not make the memory available for garbage collection. This results in failure to allocate memory due to virtual address space fragmentation. In the .NET Framework versions 1.1 and 2.0,
the large object heap is composed of contiguous areas of memory called heap segments, properly aligned to minimize virtual memory fragmentation. During garbage collection, the space reclaimed from large objects is consolidated and placed in a free list. Heap segments containing only free list items are freed and the memory is returned to the operating system. These changes to the large object heap have effectively eliminated memory allocation failures caused by this form of virtual address space fragmentation.
|
.gif) Important Note: |
|---|
On servers with more than 2GB of memory, it may be necessary to specify the /3GB switch in the boot.ini file to avoid apparent out-of-memory issues while memory is still available to the system.
|
In This Section
- Developer Backgrounds in Memory Management
Describes the adjustments developers, who have traditionally used Visual Basic, C++, and COM, should make when moving to managed code.
- Finalize Methods and Destructors
Describes how Finalize methods and destructors allow an object to perform necessary cleanup operations before the garbage collector automatically reclaims the object's memory.
- Weak References
Describes features that permit the garbage collector to collect an object while still allowing the application to access that object.
- Induced Collections
Describes how to reclaim objects immediately or at the next optimal time.
- Latency Modes
Describes the modes that determine the intrusiveness of garbage collection.
- Optimization for Shared Web Hosting
Describes how to optimize garbage collection on servers shared by hosting several small Web sites.
- Garbage Collection Notifications
Describes how to determine when a full garbage collection is approaching and when it has completed.
- Cleaning Up Unmanaged Resources
Describes the recommended design pattern for cleaning up unmanaged resources.
Reference
- System..::.GC
Provides methods for interacting with the system garbage collector.
- Object..::.Finalize
Allows an object to attempt to free resources and perform other cleanup operations before the garbage collector reclaims the object.
- System..::.IDisposable
Provides the functionality for a resource class.
Related Sections
- Garbage Collection Technology Sample
Introduces the functionality of the .NET Framework garbage collector.