Fundamentals of Garbage Collection

Fundamentals of Garbage Collection:

In the common language runtime (CLR), the garbage collector serves as an automatic memory manager. It provides the following benefits:

• Enables you to develop your application without having to free memory.
• Allocates objects on the managed heap efficiently.
• Reclaims objects that are no longer being used, clears their memory, and keeps the memory available for future allocations. Managed objects automatically get clean content to start with, so their constructors do not have to initialize every data field.
• Provides memory safety by making sure that an object cannot use the content of another object.

Fundamentals of Memory

The following list summarizes important CLR memory concepts.

• Each process has its own, separate virtual address space. All processes on the same computer share the same physical memory, and share the page file if there is one.
• By default, on 32-bit computers, each process has a 2-GB user-mode virtual address space.
• As an application developer, you work only with virtual address space and never manipulate physical memory directly. The garbage collector allocates and frees virtual memory for you on the managed heap.
• If you are writing native code, you use Win32 functions to work with the virtual address space. These functions allocate and free virtual memory for you on native heaps.
• Virtual memory can be in three states:
• Free. The block of memory has no references to it and is available for allocation.
• Reserved. The block of memory is available for your use and cannot be used for any other allocation request. However, you cannot store data to this memory block until it is committed.
• Committed. The block of memory is assigned to physical storage.
• Virtual address space can get fragmented. This means that there are free blocks, also known as holes, in the address space. When a virtual memory allocation is requested, the virtual memory manager has to find a single free block that is large enough to satisfy that allocation request. Even if you have 2 GB of free space, the allocation that requires 2 GB will be unsuccessful unless all of that space is in a single address block.
• You can run out of memory if you run out of virtual address space to reserve or physical space to commit.

Few important points:

Generations

• The heap is organized into generations so it can handle long-lived and short-lived objects. Garbage collection primarily occurs with the reclamation of short-lived objects that typically occupy only a small part of the heap. There are three generations of objects on the heap:
• Generation 0. This is the youngest generation and contains short-lived objects. An example of a short-lived object is a temporary variable. Garbage collection occurs most frequently in this generation.
• Newly allocated objects form a new generation of objects and are implicitly generation 0 collections, unless they are large objects, in which case they go on the large object heap in a generation 2 collection.
• Most objects are reclaimed for garbage collection in generation 0 and do not survive to the next generation.
• Generation 1. This generation contains short-lived objects and serves as a buffer between short-lived objects and long-lived objects.
• Generation 2. This generation contains long-lived objects. An example of a long-lived object is an object in a server application that contains static data that is live for the duration of the process.
• Configuring Garbage Collection
• You can use the element of the runtime configuration schema to specify the type of garbage collection you want the CLR to perform. When this element's enabled attribute is set to false (the default), the CLR performs workstation garbage collection. When you set the enabled attribute to true, the CLR performs server garbage collection.
• Concurrent garbage collection is specified with the element of the runtime configuration schema. The default setting is enabled. Concurrent garbage collection is available only for workstation garbage collection and has no effect on server garbage collection.
• Concurrent Garbage Collection
• In workstation or server garbage collection, you can enable concurrent garbage collection, which enables threads to run concurrently with a dedicated thread that performs the garbage collection for most of the duration of the collection. This option affects only garbage collections in generation 2; generations 0 and 1 are always non-concurrent because they finish very fast.
• Concurrent garbage collection enables interactive applications to be more responsive by minimizing pauses for a collection. Managed threads can continue to run most of the time while the concurrent garbage collection thread is running. This results in shorter pauses while a garbage collection is occurring.