The CLR and Garbage Collection

1What the CLR Does

The Common Language Runtime runs .NET code. C# compiles to IL (intermediate language) plus metadata in an assembly; at runtime the JIT compiler turns IL into machine code method by method (with tiered compilation: a quick tier-0 version first, then an optimized tier-1 version for hot methods, guided by profiling). The CLR also provides type safety, exception handling, threads, and automatic memory management.

C# source → Roslyn compiler → IL + metadata (.dll) → JIT (tier 0 → tier 1, PGO) → machine code
                                                    └ or ReadyToRun / Native AOT: compiled ahead of time

ReadyToRun precompiles IL to native code to speed up startup (still JITs hot paths later). Native AOT compiles everything ahead of time into a self-contained executable: very fast startup and small memory, but no runtime code generation, so reflection-heavy code needs care.

2The Managed Heap and Generations

Reference-type objects live on the managed heap. The GC is generational, based on the observation that most objects die young:

Allocation is just bumping a pointer, so it's very fast. A collection marks objects reachable from roots (static fields, locals on thread stacks, CPU registers, GC handles), then sweeps/compacts the rest. Survivors get promoted to the next generation.

3Workstation vs Server GC, Concurrent Collection

• Workstation GC: one heap, tuned for responsiveness of desktop apps.
• Server GC: one heap and GC thread per core, much higher throughput; the default for ASP.NET Core.
• Background (concurrent) GC collects gen 2 while application threads keep running, with only short pauses.
• DATAS (dynamic adaptation, .NET 8+) lets Server GC shrink and grow the number of heaps to save memory in containers.

Settings live in the project file or runtimeconfig.json (<ServerGarbageCollector>, <ConcurrentGarbageCollection>), and the GC respects container memory limits.

4Deterministic Cleanup: IDisposable

The GC only manages memory. Unmanaged resources (file handles, sockets, database connections) must be released explicitly:

using var stream = File.OpenRead(path);   // Dispose() called at end of scope, even on exceptions
await using var conn = new NpgsqlConnection(cs);  // IAsyncDisposable

• Implement IDisposable when your class owns a disposable resource; dispose what you own, not what you were given.
• Finalizers (~MyType()) run on a finalizer thread at some unknown time after an object becomes unreachable; they delay collection by a generation and should only exist as a safety net for raw unmanaged handles. Prefer SafeHandle.
• GC.SuppressFinalize(this) in Dispose() skips the finalizer when cleanup already happened.

5Memory Leaks in a Managed Language

The GC can't free objects that are still reachable. Typical leaks:

• Event handlers: a long-lived publisher's event holds references to every subscriber that never unsubscribes.
• Static collections and caches that only grow (use bounded caches like MemoryCache with size limits/expiry).
• Captured closures and timers that keep objects alive.
• Captive dependencies in DI: a singleton holding scoped objects.

Diagnose with dotnet-counters (heap size, gen counts, allocation rate), dotnet-gcdump/dotnet-dump and heap analysis in Visual Studio, Rider or PerfView: compare snapshots and look at retention paths.

⚠️ Common Pitfalls

1. Calling GC.Collect() to "fix" memory: it usually makes things slower; find the leak instead.
2. Not disposing HttpResponseMessage, streams, DB connections, CancellationTokenSource with timers.
3. Creating HttpClient per request (socket exhaustion); use IHttpClientFactory.
4. Allocating large buffers repeatedly (LOH churn); pool them with ArrayPool<T>.
5. Finalizers on ordinary classes: they slow the GC for no benefit.

📋 Quick Reference

C# → IL → JIT (tiered, PGO) · ReadyToRun = faster startup · Native AOT = no JIT, limited reflection
Gen0 (young, cheap) → Gen1 → Gen2 (full GC) · LOH ≥ 85,000 B · POH for pinned
Server GC (ASP.NET default) · background GC for gen2 · DATAS adapts heap count
IDisposable/using for unmanaged resources · finalizers only as a safety net (SafeHandle)
leaks = still reachable: events, static caches, closures, captive DI deps · dotnet-counters / gcdump

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: cs_clr_and_garbage_collection_theory.md · generated by tools/build_lessons.py