What is Server GC in .NET, how does DATAS change it in .NET 9 and later, and how do you tune it in containers?

1. Heaps and threads in classic Server GC

Core 0        Core 1        Core 2        Core 3
[Heap 0]      [Heap 1]      [Heap 2]      [Heap 3]
 gen0/1/2      gen0/1/2      gen0/1/2      gen0/1/2
 LOH/POH       LOH/POH       LOH/POH       LOH/POH
  ^ GC thread   ^ GC thread   ^ GC thread   ^ GC thread   (parallel mark/compact)

• Each heap's GC thread marks objects reachable from roots it owns and helps others (work stealing during mark).
• Allocation balancing moves a thread to a less busy heap if its home heap's Gen 0 is exhausted faster than others.
• Cross-heap references are normal; the heaps are one logical managed heap.

2. How DATAS adapts

At a high level:

1. Start with one heap.
2. After GCs, measure the cost of GC (time spent in GC relative to the app's work) and the live data size.
3. If GC cost is above target and the app is busy, add heaps (more parallelism, more budget).
4. If the app is quiet and GC cost is low, remove heaps and shrink budgets toward a size derived from the live data.

The Gen 0 budget in DATAS is tied to live data (bounded), instead of being tied to core count. That is why an idle 32-core service doesn't commit a huge Gen 0 per core anymore.

Side effects to know:

• Right after startup or a load spike, you may see a short period of higher GC frequency while heap count grows.
• Setting GCHeapCount fixes the count and effectively disables the adaptation.

3. Where memory goes in a pod

Container memory limit (e.g. 1 GiB)
+------------------------------------------------------------+
| Managed GC heap (default cap 75% = ~768 MiB)               |
|   gen0..2, LOH, POH, fragmentation, committed-but-free     |
+------------------------------------------------------------+
| Native: thread stacks, native libs, JIT code, R2R images,  |
|   SQL/HTTP native buffers, mmap'd files                    |
+------------------------------------------------------------+

If native usage is 300 MiB and the managed heap is allowed 768 MiB, the pod can exceed 1 GiB and be killed while the GC thinks it has room. Lower HeapHardLimitPercent (or raise the container limit) based on measured native usage.

4. Reading the configuration at run time

using System.Runtime;

var info = GC.GetGCMemoryInfo();
Console.WriteLine($"Server GC: {GCSettings.IsServerGC}");
Console.WriteLine($"CPUs visible: {Environment.ProcessorCount}");
Console.WriteLine($"GC memory limit: {info.TotalAvailableMemoryBytes / 1024 / 1024} MB");
Console.WriteLine($"High memory load threshold: {info.HighMemoryLoadThresholdBytes / 1024 / 1024} MB");
Console.WriteLine($"DATAS: {AppContext.GetData("System.GC.DynamicAdaptationMode") ?? "runtime default"}");

dotnet-counters (.NET 9+ System.Runtime metrics) and GC trace events also expose the number of heaps; in traces you can watch DATAS changing heap count over time.

5. Hexadecimal environment values

Getting this wrong is a classic incident: DOTNET_GCHeapHardLimitPercent=70 means 0x70 = 112%.

6. Multiple processes per VM

On a VM running several Server GC processes without limits, each assumes all cores: N processes × N heaps × N GC threads competing during GCs. Options: CPU limits per process/container, GCHeapCount, GCHeapAffinitizeMask/GCHeapAffinitizeRanges, or GCNoAffinitize.

7. Version notes

8. Try it yourself

1. Run the code example with DOTNET_gcServer=1, then add DOTNET_GCDynamicAdaptationMode=0; compare committed MB and Gen 0 counts.
2. Run both in Docker with --cpus=8 --memory=1g, then with no --cpus, and log ProcessorCount and TotalAvailableMemoryBytes.
3. Set DOTNET_GCHeapHardLimitPercent=70 (wrong) vs 0x46 (right) and print TotalAvailableMemoryBytes.
4. Load-test a sample ASP.NET Core app with a burst pattern (idle → heavy → idle) and watch committed memory follow the load with DATAS.
5. Allocate 300 MB of native memory with NativeMemory.Alloc in a 512 MB container and observe the OOM kill even though the GC heap is small.

using System.Runtime;

Console.WriteLine($"Server GC: {GCSettings.IsServerGC}, logical CPUs: {Environment.ProcessorCount}");
Console.WriteLine($"DATAS setting: {AppContext.GetData("System.GC.DynamicAdaptationMode") ?? "(runtime default)"}");

// Simulate request-style allocation across threads
Parallel.For(0, 2_000_000, i =>
{
    var payload = new byte[256];
    payload[0] = (byte)i;
});

GCMemoryInfo info = GC.GetGCMemoryInfo();
Console.WriteLine($"Heap size:       {info.HeapSizeBytes / 1024 / 1024} MB");
Console.WriteLine($"Committed:       {info.TotalCommittedBytes / 1024 / 1024} MB");
Console.WriteLine($"Hard limit:      {(info.TotalAvailableMemoryBytes / 1024 / 1024)} MB available to GC");
Console.WriteLine($"Gen 0 GCs:       {GC.CollectionCount(0)}");
Console.WriteLine($"Time in GC:      {GC.GetTotalPauseDuration().TotalMilliseconds:N0} ms paused");

<!-- Web SDK already enables Server GC; these are explicit for illustration -->
<PropertyGroup>
  <ServerGarbageCollector>true</ServerGarbageCollector>
  <!-- 1 = DATAS on (default with Server GC since .NET 9), 0 = off -->
  <GarbageCollectionAdaptationMode>1</GarbageCollectionAdaptationMode>
</PropertyGroup>

# Kubernetes: the GC sizes itself from these limits
resources:
  limits:
    cpu: "2"
    memory: "1Gi"
env:
  - name: DOTNET_GCHeapHardLimitPercent
    value: "0x46"   # 70% (hexadecimal) of the memory limit for the managed heap