Garbage collection is something you rarely have to worry about in our nice managed world, so before you look at what has changed in .NET 4.0, let's quickly recap how garbage collections currently works to put the new changes in context.
As you probably know, the CLR allocates memory for your applications as they require it, and assumes that an infinite amount of memory is available (you wish). This is a mad assumption, so a process called the garbage collector (GC) is needed in order to clean up unused resources. The GC keeps an eye on available memory resources and will perform a cleanup in three situations:
When a threshold is exceeded
When a user specifically calls the GC
When a low system memory condition occurs
To make this as efficient as possible, the GC divides items to be collected into "generations." When an item is first created, it is considered a generation 0 item (gen 0), and if it survives subsequent collections (it is still in use), it is promoted to a later generation: generation 1 and later generation 2.
This division allows the garbage collector to be more efficient in the removal and reallocation of memory. For example, generation 0 items mainly consist of instance variables that can be quickly removed (freeing resources earlier), while the older generations contain objects such as global variables that will probably stick around for the lifetime of your application. On the whole, the GC works very well and saves you from writing lots of tedious cleanup code to release memory.
The GC operates in a number of modes: workstation, concurrent workstation (the default for multicore machines), and server. These modes are optimized for different scenarios. For example, workstation is the default mode and is optimized for ensuring that your applications have a quick response time (important for UI-based applications), while server mode is optimized for throughput of work (generally more important for server-type applications). Server mode does pause all other managed threads during a garbage collection, however. If server mode were used for a Windows Forms application, this collection could manifest itself as intermittent pauses, which would be very annoying.
So what's changed then? Prior to .NET 4.0, a concurrent workstation garbage collection could do most but not all of a gen 0 and 1 collection at the same time as a gen 2 collection. The GC was also unable to start another collection when it was in the middle of a collection, which meant that only memory in the current segment could be reallocated.
In .NET 4.0, however, concurrent workstation garbage collection is replaced by background garbage collection. The simple explanation (and garbage collection gets very complex) is that background garbage collection allows another garbage collection (gen 0 and 1) to start at the same time that an existing full garbage collection (gen 0, 1, and 2) is running, reducing the time that full garbage collections take. This means that resources are freed earlier and that a new memory segment could be created for allocation if the current segment is full.
Background collection is not something you have to worry about—it just happens and will make your applications perform more quickly and be more efficient, so it's yet another good reason to upgrade your existing applications to .NET 4.0.
Background collection is not available in server mode garbage collection, although the CLR team has stated that they are aiming to achieve this in the next version of the framework. The garbage collection team has also done work to ensure that garbage collection works effectively on up to 128 core machines and that the GC's efficiency is improved, reducing the time needed to suspend managed threads.
For more information and a detailed interview with the improved the team, please refer to http://blogs.msdn.com/ukadc/archive/2009/10/13/background-and-foreground-gc-in-net-4.aspx and http://channel9.msdn.com/shows/Going+Deep/Maoni-Stephens-and-Andrew-Pardoe-CLR-4-Inside-Background-GC.
It is worth noting that starting with .NET 3.5 SP1, the CLR has a method called GC.RegisterForFullGCNotification() that lets you know when a gen 2 or large-heap object collection occurs in your applications. You might want to use this information to route users to a different server until the collection complete, for example.
3.137.178.169