What is Workstation GC in .NET, when is it the default, and when would you choose it over Server GC?

1. Where the GC runs

In Workstation GC there are no dedicated GC worker threads for blocking collections. When an allocation exhausts the Gen 0 budget, that thread:

1. Requests suspension of all other managed threads.
2. Performs mark/plan/relocate/compact itself.
3. Resumes everyone.

The background GC thread only does concurrent Gen 2 marking and sweeping. Consequence: on a many-core machine, a blocking GC uses one core to do the work while others wait. Server GC parallelises the same work across GC threads, which is why it wins on throughput with heavy allocation.

2. Budgets and pause behaviour

Workstation:  |g0|..|g0|..|g0|..|g0|..|g0|..   small budget, frequent short GCs
Server:       |  g0  |........|  g0  |.......   bigger per-heap budgets, fewer GCs, more memory

Workstation's smaller Gen 0 budget (related to CPU cache sizes) keeps the heap small and each pause short, but you'll see more GCs per second for the same allocation rate.

3. Concurrent vs non-concurrent internals

For a CLI tool that runs for 20 seconds and exits, non-concurrent can be marginally faster and lighter.

4. Containers and CPU limits

• The runtime reads cgroup CPU and memory limits.
• Environment.ProcessorCount reflects the CPU limit (rounded up), not host cores.
• Server GC needs more than one effective CPU to create multiple heaps; with one, it behaves like Workstation.
• Default GCHeapHardLimit = max(20 MB, 75% of the container memory limit) when a limit exists.
• DOTNET_PROCESSOR_COUNT can override the CPU count the runtime sees (useful when CPU limits are unusual).

5. Other knobs that matter with Workstation GC

6. Measuring the choice

Run the same load test twice, changing only DOTNET_gcServer:

Pick the mode that meets latency SLOs at the lowest memory and CPU cost.

7. Version notes

8. Try it yourself

1. Run the code example and note IsServerGC, LatencyMode, Gen 0 count and committed memory.
2. Run again with DOTNET_gcServer=1 and compare Gen 0 count and committed MB.
3. Run with DOTNET_gcConcurrent=0 and confirm LatencyMode becomes Batch.
4. Run inside Docker with --cpus=1 --memory=256m and with --cpus=4; compare ProcessorCount, TotalAvailableMemoryBytes and heap sizes.
5. Load-test a small ASP.NET Core app with both modes using bombardier -c 50 -d 60s, and chart latency and memory side by side.

using System.Runtime;

Console.WriteLine($"Server GC:     {GCSettings.IsServerGC}");
Console.WriteLine($"Latency mode:  {GCSettings.LatencyMode}");   // Interactive = background workstation, Batch = non-concurrent
Console.WriteLine($"CPU count:     {Environment.ProcessorCount}");

int gen0 = GC.CollectionCount(0);
for (int i = 0; i < 5_000_000; i++) _ = new byte[100];

GCMemoryInfo info = GC.GetGCMemoryInfo();
Console.WriteLine($"Gen 0 GCs:     {GC.CollectionCount(0) - gen0}");
Console.WriteLine($"Heap size:     {info.HeapSizeBytes / 1024 / 1024} MB");
Console.WriteLine($"Committed:     {info.TotalCommittedBytes / 1024 / 1024} MB");
Console.WriteLine($"Memory limit:  {info.TotalAvailableMemoryBytes / 1024 / 1024} MB");

<PropertyGroup>
  <ServerGarbageCollector>false</ServerGarbageCollector>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>