Maoni Stephens, Dev Owner of the CLR GC, and Andrew Pardoe, PM of the CLR GC, explain in a Channel 9 interview the introduction of the Background GC in CLR 4 which basically allows the start of yet another GC while the first is running, improving the efficiency of the garbage collection process.
Until now there have been two GC types: Workstation and Server. The Workstation GC could be run with Concurrency ON or OFF.
Workstation/Concurrency OFF – When the managed thread responsible for memory allocations runs out of available space, it calls the GC which runs in the same thread. The GC suspends all other managed threads, clears up some memory, resumes the work of the suspended managed threads and returns the control to the original thread.
Workstation/Concurrency ON, also called Concurrent GC. – Like in the previous scenario, but the GC does not suspend the managed threads for the entire period when it reclaims unused memory. It allows managed threads to continue their work including memory allocation, but with some limitations described below. The memory pool for gen0 objects is considerably larger then for the previous scenario to be able to serve allocation needs. The threads are still suspended if there is no more memory available.
Maoni details the concurrent GC:
[Concurrent GC] allows you to allocate while a concurrent GC is in progress. However you can only allocate so much – for small objects you can allocate at most up to end of the ephemeral segment. Remember if we don’t do an ephemeral GC, the total space occupied by ephemeral generations can be as big as a full segment allows so as soon as you reached the end of the segment you will need to wait for the concurrent GC to finish so managed threads that need to make small object allocations are suspended.
During a concurrent GC we need to suspend managed threads twice to do some phases of the GC. These phases could possibly take a while to finish.
Server – In this case there is a GC running in its own thread and a memory heap for each CPU. When the allocating thread runs out of available space, it will signal this to the corresponding GC thread which will suspend all managed threads running on the respective CPU, will clean up the memory, will signal it has finished its work and will resume the suspended threads.
The Workstation/Concurrency OFF and Server types are called blocking GC because there is no activity going on when the GC runs.
Choosing a GC type is done through the runtime configuration files by setting
.NET 4.0 introduces Background GC. The Concurrent GC allocates memory while running but in the current segment which is 16 MB on a workstation. After that all threads are suspended. The Background GC allows a separate ephemeral GC - gen0 and gen1 - to be started while the full GC - gen0, 1, and 2 - is running and that means access to another memory segment, as explained by Maoni:
Background GC is an evolution to concurrent GC. The significance of background GC is we can do ephemeral GCs while a background GC is in progress if needed. As with concurrent GC, background GC is also only applicable to full GCs and ephemeral GCs are always done as blocking GCs, and a background GC is also done on its dedicated GC thread. The ephemeral GCs done while a background GC is in progress are called foreground GCs
Background GC won’t be available for servers in CLR 4.0 but it is under consideration to be introduced in a later version. In the meantime, the documentation advises:
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.
Also, one can make use of the notification mechanism provided in .NET 3.5. The GC can be set up to inform when a collection is imminent and after it has finished. This allows to balance the work between different servers to avoid being interrupted by the GC.