When an application is executed in the .NET Framework, the garbage collector allocates a section of memory to store and manage the objects declared during the application execution. 

This memory is referred to as the managed heap. It's called "managed" because it's used to save the managed variables. The following diagram illustrates what a typical heap structure looks like:

The preceding diagram is a typical example of what a heap structure looks like. At the top of the structure, we have a root node. Each node can have two child nodes. The address of the child node is saved in the parent node itself.

The garbage collector allocates and deallocates memory on this managed heap. The heap is referred to as the managed heap. When an object is allocated in the application, the object is stored in the heap. The object then saves the reference to the next object in the heap.

While allocating the memory, the CLR checks whether any free memory is available in the heap. If memory is available, it allocates it from the heap. However, every so often, the garbage collector performs a check on all of the objects present in the managed heap and checks whether the object is being used in the application. The garbage collector loops through the heap and finds out which objects are not associated with the application root as well as those that are not referred to anywhere in the heap. These objects are classified as dead objects. The garbage collector then removes such dead objects from the heap. 

Before we can begin to understand the phases in which the garbage collector works, let's understand how the garbage collector segregates the managed heap into different divisions called generations.