Tech Notes: Garbage Collection

Saturday, March 1, 2008

Unmanaged resourse:

Most types, including String, Attribute, Delegate, and Exception, represent resources that don't require any special cleanup.
A type that represents an unmanaged or native resource, such as a file, a database connection, a socket, a mutex, a bitmap, an icon, and so on, always requires the execution of some cleanup code when the object is about to have its memory reclaimed.

Root:

Every application has a set of roots.
A single root is a storage location containing a memory pointer to a reference type object.
Only variables that are of a reference type are considered roots; value type variables are never considered roots.

Two phases:

1. Marking phase:

GC go through the stack, checking all the roots, if a root is found to refer to an object, the object is marked.
Once all of the roots have been checked, the heap contains a set of marked and unmarked
objects.
The marked objects are reachable via the application's code, and the unmarked objects
are unreachable.
The unreachable objects are considered garbage, and the memory that they occupy can be reclaimed.

2. Compact phase:

This is when the collector traverses the heap linearly looking for contiguous blocks of unmarked (garbage) objects.
If small blocks are found, the garbage collector leaves the blocks alone. If large free contiguous blocks are found, however, the garbage collector shifts the nongarbage objects down in memory to compact the heap.

3 Generations:

Generations are a mechanism within the CLR garbage collector whose sole reason for being is to improve an application's performance.
Objects in generation 0 are newly constructed objects that the garbage collector has never examined.
When the CLR initializes, it selects a budget size for generation 0 of, say, 256 KB. (The exact size is subject to change.) So if allocating a new object causes generation 0 to surpass its budget, a garbage collection must start.
After one collection: generation 0 survivors are promoted to generation 1; generation 0 is empty.
When the CLR initializes, it selects a budget for generation 0. It also selects a budget for generation 1. Let's say that the budget selected for generation 1 is 2 MB.
If generation 1 occupies less than 2 MB, so the garbage collector examines only the objects in generation 0 which will speed up the garbage collection process.
So if allocating a new object causes generation 0 to surpass its budget, a garbage collection must start. Generation 0 survivors are promoted to generation 1. At this time, if generation 1's budget is full, generation 1 survivors are promoted to generation 2.
The managed heap supports only three generations: generation 0, generation 1, and generation 2; there is no generation 3.
When future collections occur, any surviving objects currently in generation 2 simply stay in generation 2.

Assumptions:

Unmanaged resourse:

Most types, including String, Attribute, Delegate, and Exception, represent resources that don't require any special cleanup.
A type that represents an unmanaged or native resource, such as a file, a database connection, a socket, a mutex, a bitmap, an icon, and so on, always requires the execution of some cleanup code when the object is about to have its memory reclaimed.

Root:

Every application has a set of roots.
A single root is a storage location containing a memory pointer to a reference type object.
Only variables that are of a reference type are considered roots; value type variables are never considered roots.

Two phases:

1. Marking phase:

GC go through the stack, checking all the roots, if a root is found to refer to an object, the object is marked.
Once all of the roots have been checked, the heap contains a set of marked and unmarked
objects.
The marked objects are reachable via the application's code, and the unmarked objects
are unreachable.
The unreachable objects are considered garbage, and the memory that they occupy can be reclaimed.

2. Compact phase:

This is when the collector traverses the heap linearly looking for contiguous blocks of unmarked (garbage) objects.
If small blocks are found, the garbage collector leaves the blocks alone. If large free contiguous blocks are found, however, the garbage collector shifts the nongarbage objects down in memory to compact the heap.

3 Generations:

Generations are a mechanism within the CLR garbage collector whose sole reason for being is to improve an application's performance.
Objects in generation 0 are newly constructed objects that the garbage collector has never examined.
When the CLR initializes, it selects a budget size for generation 0 of, say, 256 KB. (The exact size is subject to change.) So if allocating a new object causes generation 0 to surpass its budget, a garbage collection must start.
After one collection: generation 0 survivors are promoted to generation 1; generation 0 is empty.
When the CLR initializes, it selects a budget for generation 0. It also selects a budget for generation 1. Let's say that the budget selected for generation 1 is 2 MB.
If generation 1 occupies less than 2 MB, so the garbage collector examines only the objects in generation 0 which will speed up the garbage collection process.
So if allocating a new object causes generation 0 to surpass its budget, a garbage collection must start. Generation 0 survivors are promoted to generation 1. At this time, if generation 1's budget is full, generation 1 survivors are promoted to generation 2.
The managed heap supports only three generations: generation 0, generation 1, and generation 2; there is no generation 3.
When future collections occur, any surviving objects currently in generation 2 simply stay in generation 2.

Assumptions:

Tech Notes