.NET runtime: CLR, JIT & GC

#The .NET family and support policy

Choose a platform by deployment needs and upgrade deadlines. Similar names do not make an old application compatible with a new runtime without changes.

Even releases are LTS with three years of support; odd releases are STS. Starting with .NET 9, STS support is 24 months. Both .NET 8 and .NET 9 reach end of support in November 2026. Staying supported also requires applying servicing and security updates.

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

The commands inspect the environment, installed build tools and installed runtimes respectively. An SDK on a developer machine says nothing about a server's installed runtime.

#From C# to IL: CLR, CTS and CLS

Languages need a shared representation of code and types to exchange libraries. Think of IL as shared instructions and the runtime as the execution manager that translates them and manages resources.

C# source
  -> Roslyn compiler
  -> Assembly: IL + metadata + manifest
  -> Runtime loader and type system
  -> JIT -> native instructions -> CPU
           GC, exceptions, threading and interop

• CLR: Common Language Runtime, often used to describe execution services. CoreCLR is a principal modern .NET runtime; other runtimes serve other workloads.
• IL: Intermediate Language, not CPU instructions. Portability also depends on libraries and native dependencies.
• CTS: Common Type System, defining how types are represented and used, including value and reference types.
• CLS: Common Language Specification, a common subset of rules for public APIs usable across .NET languages. Unsigned types, for example, are not CLS-compliant.

[assembly: CLSCompliant(true)]
public static class InvoiceMath
{
    public static decimal AddTax(decimal total) => total * 1.14m;
}

The attribute asks the compiler to check the public API against CLS rules; it does not make native dependencies cross-platform.

#Classic JIT types and their modern equivalents

The three-JIT question uses historical terminology. Name the three, then explain that modern .NET does not expose them as three selectable operating modes.

# Alternatives: publish the same project in different modes.
dotnet publish -c Release -r linux-x64 --self-contained false
dotnet publish -c Release -r linux-x64 -p:PublishReadyToRun=true
dotnet publish -c Release -r linux-x64 -p:PublishAot=true

The commands select ordinary JIT deployment, R2R and Native AOT, provided the project and dependencies support AOT. NGen and Native AOT are not the same implementation.

#Tiered compilation, OSR and dynamic PGO

Optimizing every method before the first request delays startup; keeping all code minimally optimized hurts throughput. The runtime balances the two in stages.

1. Tier 0 provides quickly generated code; ReadyToRun can supply initial precompiled code.
2. The runtime observes usage and recompiles hot methods at Tier 1 with stronger optimizations.
3. On-Stack Replacement can transfer a running long loop into optimized code.
4. Dynamic PGO collects actual branch and type profiles for inlining and guarded devirtualization. It is enabled by default from .NET 8 in typical configurations.

<PropertyGroup>
  <TieredCompilation>true</TieredCompilation>
  <TieredPGO>true</TieredPGO>
</PropertyGroup>

The settings enable tiering and profile guidance respectively; they illustrate the controls rather than a required project change. No fixed promotion call count is guaranteed. Measure startup separately from steady-state behavior; a single cold call can mislead.

#Choosing JIT, ReadyToRun or Native AOT

Choose publishing mode according to cold starts, memory and compatibility, rather than novelty.

#Stack and heap: storage versus semantics

Value versus reference explains copying; stack versus heap explains storage and lifetime. These are different questions. A thread's stack is working space, while the managed heap holds objects whose lifetimes need not follow a single call.

public struct Quantity { public int Value; }
public sealed class OrderLine { public Quantity Quantity; }

var line = new OrderLine();                 // (1)
line.Quantity.Value = 2;
var copy = line.Quantity;                   // (2)
copy.Value = 9;
object boxed = copy;                        // (3)
Console.WriteLine(line.Quantity.Value);     // 2

References themselves may be locals or fields. Closures and async state machines can move local state onto the heap. Choosing a struct does not guarantee allocation-free code.

#GC generations, LOH and background collection

Most temporary objects die quickly, so frequent small collections are cheaper than repeatedly scanning the whole heap. GC traces reachability from roots such as live locals, static fields and GC handles.

• Small objects typically start in Gen0. Survivors may move to Gen1 and Gen2. A Gen2 collection includes younger generations.
• The LOH holds large objects, normally at least 85,000 bytes including object overhead. It is collected with Gen2 and generally is not compacted by default.
• Background GC performs much Gen2 work concurrently with application execution; it still has pauses and stop-the-world phases.
• Compaction can move objects and update references. Pinning prevents movement and may increase fragmentation.

byte[] small = new byte[1024];
byte[] large = new byte[100_000];
Console.WriteLine(GC.GetGeneration(small));  // typically 0 if no GC intervenes
Console.WriteLine(GC.GetGeneration(large));  // 2: LOH is collected with Gen2

The first result can change if a collection intervenes. This is an illustration, not an application assertion. Avoid forcing GC.Collect() after requests; address allocation rate and retention first.

#Server GC, workstation GC and DATAS

A high-throughput service has different needs from an interactive desktop application. Workstation GC suits interactive or resource-constrained workloads. Server GC uses multiple heaps and workers for throughput, potentially consuming more memory.

Dynamic Adaptation to Application Sizes adapts server GC to long-lived data and workload needs, including changing heap counts. Introduced in .NET 8, DATAS is enabled by default for server GC from .NET 9. It does not replace memory limits or fix leaks.

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>

The settings request server GC and background collection. Hosting and environment affect the actual mode; inspect GCSettings.IsServerGC. Compare p95 and p99 latency, throughput and memory under the intended container limits. DATAS documentation.

#Dispose, finalizers and SafeHandle

GC reclaims unreachable managed memory, but a file handle or connection needs predictable release. Dispose provides deterministic cleanup; a finalizer is a fallback with unpredictable timing and no process-exit guarantee.

// An inheritable owner of a managed disposable resource.
public class InvoiceFile : IDisposable
{
    private bool _disposed;
    private readonly FileStream _stream = File.OpenWrite("invoice.txt");

    public void Write(byte[] bytes)
    {
        ObjectDisposedException.ThrowIf(_disposed, this); // (1)
        _stream.Write(bytes);
    }

    public void Dispose()
    {
        Dispose(true);                                  // (2)
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;
        if (disposing) _stream.Dispose();                // (3)
        _disposed = true;
    }
}

using var file = new InvoiceFile();                      // (4)
file.Write([65, 66]);

A sealed class owning only a stream needs a simpler Dispose method. Implementing IDisposable does not require adding a finalizer. For raw native handles, prefer SafeHandle and put native release logic in ReleaseHandle; the owner disposes the SafeHandle. In the older pattern that directly owns a raw resource, a finalizer calls Dispose(false) without accessing managed objects. Use IAsyncDisposable and await using for asynchronous cleanup.

#Memory leaks, assemblies and deployment units

A managed leak consists of reachable objects the application no longer needs: unbounded caches, subscriptions to long-lived publishers, timers, or singletons retaining scoped services. Native leaks can increase working set without increasing the managed heap.

1. Observe memory under stable load and after idle time; distinguish working set from live managed heap.
2. Inspect allocation rate, Gen2, LOH and collection counters.
3. Compare gcdumps captured at two points and inspect retained types and reference paths. Use a process dump and gcroot when deeper root analysis is needed.
4. Fix ownership or lifetime, then repeat the scenario. Dump capture can pause the process and expose sensitive data.

# Install the diagnostic tools separately if needed.
dotnet-counters monitor --process-id 1234 --counters System.Runtime
dotnet-gcdump collect --process-id 1234 --output orders.gcdump
dotnet-gcdump report orders.gcdump

The commands monitor runtime metrics, capture a managed heap graph and print a report. The text report is a starting point; reference-path analysis needs a suitable viewer. dotnet-gcdump reference.

Self-contained does not mean single-file or Native AOT. P/Invoke connects managed code to native APIs and requires correct type and ownership contracts.