Server GC Misconceptions
One of the most common “bugs” I read about on the Microsoft public newsgoups is the fact that the runtime does not automatically choose Server GC mode on a multi-proc machine, or server OS.
If the server OS is running on a single-proc machine then the runtime will have to load the Workstation GC, since Server GC doesn’t work on a single proc, so we’re down to just the multi-proc issue.
Let’s imagine for a minute that the runtime did choose Server GC on its own.
If Server GC is automatically enabled, then all applications, both applications running as services and user applications will use this GC mode. This is good news for the services, but bad news for the user applications.
Like I explained in my previous post, user applications are best run with Concurrent GC, to maximize responsiveness. Unfortunately, Server GC and Concurrent GC are incompatible, so the runtime has effectively made user applications perform worse on a multi-proc machine than they do on a single proc! And since there’s no way to specify which GC mode to use (in v1.0 and v1.1 pre-SP1), you’re stuck with services with optimized throughput, and laggy user interfaces. This really sucks if you happen to have bought a brand new machine with a Hyperthreaded processor, and want to run managed apps on it!
The CLR Team decided on behaviour with the least negative performance impact, so you either have to host your service if you want it run with Server GC, or use config files.