How does C# code execute (IL, JIT, AOT)?

Question

Accepted Answer

C# doesn't compile directly to machine code. It compiles to **IL** (Intermediate Language) — a platform-independent bytecode — which the **CLR** runs, using **JIT** (Just-In-Time) compilation to translate IL to native machine code at runtime. **AOT** (Ahead-Of-Time) is an alternative that compiles to native code at build time.

## The execution pipeline

```text
C# source (.cs)
   │  C# compiler (roslyn)
   ▼
IL bytecode (in a .dll/.exe assembly)  ← platform-INDEPENDENT intermediate code
   │  CLR loads it; JIT compiles IL → native code AT RUNTIME (per method, as called)
   ▼
Native machine code → executes on the CPU
```

The C# compiler produces **IL** (a CPU-independent bytecode), packaged in an assembly. At runtime, the **CLR** (Common Language Runtime) uses the **JIT compiler** to translate IL methods to native machine code as they're first called — and the native code is cached for subsequent calls.

## Why IL + JIT? Benefits

```text
✓ Platform independence — the SAME IL runs on any platform with a CLR
✓ Runtime optimization — the JIT optimizes for the ACTUAL hardware it runs on
✓ Language interoperability — C#, F#, VB all compile to IL → can interoperate
✓ The CLR provides GC, type safety, security on top
```

IL + JIT gives platform independence (one assembly, any platform with a runtime) and lets the JIT optimize for the specific hardware. (There's a startup cost as methods are JIT-compiled on first use.)

## AOT — Ahead-Of-Time compilation

```text
Native AOT (modern .NET) → compiles directly to native machine code at BUILD time.
  ✓ FASTER startup (no JIT at runtime), smaller deployment, lower memory
  ✓ Good for: serverless, CLI tools, containers (where fast startup matters)
  ✗ Trade-offs: no runtime JIT optimization, some reflection/dynamic limitations
JIT (default) → flexible, runtime-optimized, but has startup/warm-up cost.
```

**AOT** compiles to native code at build time — eliminating the JIT startup cost (faster startup, smaller, less memory), valuable for serverless and CLIs, at the cost of some flexibility.

## Why it matters

Understanding how C# code executes — the **IL → JIT → native** pipeline — is valuable knowledge for understanding the .NET platform deeply, explaining its capabilities, and making informed decisions about deployment and performance.

The key insight is that C# compiles to **IL** (platform-independent bytecode) rather than native code, and the **CLR** uses **JIT compilation** to translate it to native code at runtime — which is what enables .NET's platform independence (the same compiled assembly runs anywhere with a runtime), runtime optimization (the JIT optimizes for the actual hardware), and language interoperability (C#, F#, VB all compile to IL).

This explains behaviors like the JIT startup/warm-up cost (relevant when benchmarking or optimizing startup).

Understanding **AOT** (Native AOT, a modern alternative compiling to native code at build time) is increasingly important for specific scenarios: it provides **faster startup, smaller deployments, and lower memory** (valuable for serverless functions, CLI tools, and containers where startup time and size matter), at the cost of runtime JIT optimization and some reflection/dynamic limitations — so knowing the JIT-vs-AOT trade-off helps you choose the right approach for a deployment target.

While this is more conceptual than day-to-day coding knowledge, understanding the execution model (IL/JIT/AOT) is valuable for explaining how .NET achieves platform independence and performance, for reasoning about startup performance, and for making deployment decisions (especially the growing relevance of AOT for cloud-native scenarios) — making it worthwhile senior-level knowledge that demonstrates deep understanding of the .NET platform and is a relevant topic for performance- and deployment-focused discussions.