Changing Your Garbage Collector Settings on the Fly (.NET Memory Management: Part 5)

August 20, 2008 Rick Minerich

It has come to my attention via a recent DZone article that .NET 3.5 and 2.0 SP1 jointly included a new feature which lets you manipulate the way your garbage collector acts programmatically.  This can be done through changing the value of a new property of the System.Runtime.GCSettings class named LatencyMode. In this article I will walk you through this new property and the different effects of each of it's possible settings.

Other Articles in This Series

Part 1 - Basic Housekeeping
Part 2 - Improving Performance Through Stack Allocation
Part 3 - Increasing the Size of the Stack
Part 4 - Garbage Collector Settings  
Part 5 - Changing Your Garbage Collector Settings on the Fly



The new LatencyMode property accepts three different enumerated values.  The first two of which are Batch and Interactive which correspond to turning <gcConcurrent> on and off inside of your application configuration.  However, the effects of the third value, which is named LowLatency, were previously unavailable by any means.  By setting this the LatencyMode to LowLatency you can now put the Garbage Collector in an ultra-conservative mode which will insure the application will be interrupted as infrequently as possible. 

There are a couple of things you should take note of before changing your Garbage Collector's LatencyMode:

  • LatencyMode settings are process-wide and so all of the threads in your application will be effected.
  • Changing LatencyMode will have no effect if your application has <gcServer> mode set in its configuration file.

Now, let’s explore each of the possible values of LatencyMode in detail:



When it’s useful:  
It’s useful in applications without a UI and in Server Based Software.  It may also be useful to switch your garbage collector into Batch latency mode if your application has a data crunching mode which occurs after a user interface.

What it does:
This is the most intrusive setting.  Garbage Collection is done non-concurrently in one big batch call. Your program will be suspended while garbage collection takes place.

This is the default value when <gcConcurrent> is disabled.

Even though this will be the enumeration which will be set if <gcServer> is enabled, the garbage collector will act as described in my previous article.  In fact, if you have your application defined to be in <gcServer> mode the LatencyMode property cannot be changed from its default of “Batch”.


When it’s useful:
It’s the best mode for most any UI-based application.

What it does:
This is the most balanced setting.  Garbage Collection happens concurrently with your application.  Most of the work is done in a separate thread and although your application will be suspended it will not happen very often and for only very short periods of time.

This is the default value for garbage collection on workstations.  If <gcConcurrent> is left at its default value, this is the type of garbage collection that will occur.


When it’s useful:
It’s useful for time sensitive applications such as 3d rendering or data acquisition.

What it does:
This is the least intrusive mode the Garbage Collector can be set to.  As in Interactive, garbage collections happen concurrently with your application.  However, collection of older objects will only happen when memory pressure becomes high.  Collection of generation 2 objects is kept to a bare minimum.

This is never the default setting.

LowLatency mode was designed for short time use only during time-critical sections of your application.  Leaving an application in LowLatency mode for an extended period of time will cause unused objects accumulate.  Before using low latency mode, you should take a look at the guidelines laid out at the bottom of the MSDN Latency Modes page.

MSDN Visual Studio 2008 Developer Center – Latency Modes
MSDN .NET Framework Developer Center – GCLatencyMode Enumeration
DZone - Low-Latency GC in .NET 3.5


About the Author

Rick Minerich

Rick Minerich is a former Software Architect at Atalasoft, F# MVP, and is currently the Director of Research and Development at Bayard Rock. To read more articles from Rick please visit his blog:

Follow on Twitter More Content by Rick Minerich
Previous Article
Wow, It’s Been Quiet
Wow, It’s Been Quiet

Have you heard the crickets?  I’m not surprised.  The one thing you can...

Next Article
Choosing the Right Garbage Collector Settings for Your Application (.NET Memory Management: Part 4)
Choosing the Right Garbage Collector Settings for Your Application (.NET Memory Management: Part 4)

Tuning the garbage collector to the specific context of the particular...

Try any of our Imaging SDKs free for 30 days with Full Support

Download Now