Changes in GC in Orcas

People usually have this belief that calling GC.Collect() manually would reduce memory usage of their application and hence increase its performance. Well, to an extend I would agree, but I would add that it can also potentially hamper the performance. The reason I used the word "potentially" is that this reduction of memory usage is made at the cost of an "out of cycle" garbage collection.

"Out of cycle" garbage collection holds good, as long as we have objects to be reclaimed. But what if there is no objects to be reclaimed ? You may have a performance hit here because, even thought GC runs its cycle very quickly, it would need require to freeze your applications main thread before starting the collection cycle. Once the cycle is done, the thread is unfrozen.

So what does Orcas do in this regard ?
Orcas adds an overload to the GC.Collect Method.

void System.GC.Collect(int generation, System.GCCollectionMode mode)

According to the MSDN Documentation, this "forces a garbage collection from generation zero through a specified generation, at a time specified by the GCCollectionMode."

The different values mode can be are

* Default: the same behavior if you called GC.Collect without specifying the mode. Currently this is the same behavior as Forced, but this is subject to change in future versions of the runtime.
* Forced: guarantees a collection occurs for all the generations up to and including generation.
* Optimized: this mode will tell the GC to only collect if it determines that a collection will be productive. In this case, “productive” is determined by a number of factors, including amount of memory considered garbage, heap fragmentation, etc. The exact formula is subject to change between CLR releases. If the GC decides a collection will not be productive, then the call will have no effect.

Another Change : GC Latency modes

There are mainly 3 different Latency modes ( Server GC, Workstation GC and Concurrent GC). There settings are process wide and set at the beginning of the process. Once set these cannot be changed.

What is being changed in Orcas is that, though being process wide, the latency modes can be changed using System.Runtime.GCSettings.LatencyMode property, during the lifetime of the application.

The values for GCLatencyMode are Batch, Interactive and LowLatency.

* Batch: This mode is designed for maximum throughput, at the expense of responsiveness. It is best for applications with no UI or server-side operations and is equivalent to Workstation GC without Concurrent GC. If Concurrent GC is enabled, switching to Batch mode will prevent any further concurrent collections. This is the only valid mode for Server GC.
* Interactive: This mode balances responsiveness with throughput. It is designed for applications with UI and is the default Latency Mode, equivalent to Workstation GC with Concurrent GC. This mode is not available on Server GC.
* LowLatency: This mode is meant for short-term, time-sensitive operations where interruptions from the GC may be disruptive, like animation rendering or data acquisition functions. This mode is not available on Server GC.

Conclusion
Even with new additions , manually invoke is not recommended until and unless the call is unavoidable. However, can't resist in saying that it seems we are going to have a more flexible and power GC for the next edition of framework.