Memory & GC
using System.Runtime;
using System.Runtime.InteropServices;
Console.WriteLine($"framework:{RuntimeInformation.FrameworkDescription}");
Console.WriteLine($"server-gc:{GCSettings.IsServerGC}");
Console.WriteLine($"max-generation:{GC.MaxGeneration}");
Console.WriteLine($"processors:{Environment.ProcessorCount}");
Console.WriteLine("runtime-observation:values-vary");
Reveal answer and reasoning
The portable example prints framework description, whether server GC is active, the reported maximum generation and processor count. These values can differ across the app runtime and desktop SDK. Their variation is expected, so the lesson intentionally has no fixed expected transcript. The final line labels the output as runtime observations instead of inventing one desktop answer for every platform.
Processor count is a runtime observation under the current host environment, not proof of how many physical cores are available exclusively to the service. Likewise IsServerGC tells you the effective GC flavor, not whether that choice is optimal. A maximum generation value does not identify the physical region of an arbitrary object or describe Unity's collector. Keep the meaning of each printed value narrow and explicit.
The SDK program records CoreCLR framework, effective server mode, visible processors, latency mode and GCMemoryInfo values after a bounded educational collection. It does not modify the machine's container settings, GC policy or startup environment. Run separate processes with deliberately chosen startup configurations when comparing modes, and record those configurations alongside results.
A realistic comparison includes steady traffic, a burst, downstream slowness and an idle recovery interval. Track completed throughput, tail latency, allocation rate, pause time, retained live bytes, committed GC bytes and process memory. Record CPU quota and memory quota because a configuration that works on a development laptop can behave differently in a constrained container. Never change several GC knobs and the application workload simultaneously if you want a useful causal explanation.
What a strong answer covers
- Server GC, background GC and DATAS describe different decisions.
- Managed heap limits leave native and other process memory outside their budget.
- Read effective settings under the real CPU and memory constraints.
Common pitfall
Treating a managed heap limit as a whole-process limit, or assuming a project setting proves the effective runtime mode.
Follow-up questions
- Which startup setting, numeric unit and parsing rule are you verifying?
- How would CPU quota alter the configuration comparison?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.