How C# Code Executes: IL, JIT, ReadyToRun and Native AOT

Welcome to Production .NET — where "it works" isn't enough anymore. Now you need to know why it works.

You've written hundreds of methods, launched dozens of apps, and typed dotnet run more times than you can count. Every time, the same thing happens: your C# turns into a running program. But have you ever stopped to ask what actually happens in the half-second between hitting Enter and seeing output on screen?

It's not magic, and it's not a single step. Your C# source code goes through two separate compilations — one you control (at build time) and one you don't (at run time) — before a single CPU instruction executes. Understanding this pipeline is the foundation for everything else in this Advanced tier: garbage collection, JIT tuning, memory layout, and performance diagnostics all sit on top of it.

In this lesson, you'll trace the complete journey from the C# you type to the machine code your CPU actually runs — and meet the two compilers, the runtime, and the alternatives to the default pipeline that modern .NET offers.

What Is It?

The Simple Explanation

Running a C# program is a two-stage translation, not one:

• Stage 1 (build time): The Roslyn compiler turns your .cs files into IL (Intermediate Language) — a CPU-independent instruction set — and packages it into an assembly (a .dll or .exe) along with metadata describing every type, method, and field.
• Stage 2 (run time): When you actually run the program, the CLR loads that assembly and its JIT compiler translates the IL into real, CPU-specific machine code — the only thing a processor can actually execute.

You already met this pipeline at a high level back in Foundations. This lesson goes underneath it — the actual mechanics of tiered JIT compilation, and the alternatives (ReadyToRun, NativeAOT) that reshape when that second translation happens.

The Technical Definition

Roslyn is the open-source C# (and Visual Basic) compiler platform. It performs lexing, parsing, semantic analysis, and code generation, emitting IL plus metadata into a Portable Executable (PE) file — the assembly.

The CLR (Common Language Runtime) is the execution engine that loads assemblies, verifies them, and hosts the JIT (Just-In-Time) compiler, which compiles IL to native machine code method by method, on demand, the first time each method actually runs. Modern .NET uses tiered compilation: a fast, lightly-optimized pass (Tier 0) gets code running quickly, and a slower, heavily-optimized recompilation (Tier 1) kicks in later for methods that turn out to be "hot" (called frequently).

Why Does It Exist?

The Problem

Imagine .NET skipped IL entirely and Roslyn compiled C# straight to native x64 machine code, the way a C compiler does. That would create real problems:

• No portability — you'd need a separate build for x64, Arm64, Windows, Linux, macOS... every target would need its own compiled artifact.
• No runtime services — things like garbage collection, exception handling, and type safety checks need the runtime to understand what the code is doing structurally. Raw machine code has already thrown that structure away.
• No adaptive optimization — a compiler working ahead of time can't know which CPU features are actually available at runtime, or which methods will actually run hot in your specific deployment.

Now imagine the opposite extreme: the JIT does its absolute best optimization pass on every single method, the instant the program starts. That has a different problem — startup would be brutally slow, because full optimization (inlining, register allocation, loop unrolling) is expensive to compute, and most methods only run a handful of times.

The Solution

.NET's answer is layered:

• Compile to IL, not native code, at build time — this gives portability (write once, the same DLL runs anywhere .NET runs) and preserves the structural information the CLR needs for GC, type safety, and reflection.
• JIT lazily, per method, at run time — a method that's never called is never compiled at all. Startup only pays for the code paths actually exercised.
• Compile in tiers — get something running fast (Tier 0), then spend real optimization effort only on the methods that prove, by actually being called a lot, that the investment is worth it (Tier 1).

This is a deliberate trade-off between startup latency and peak throughput — and it's tuned automatically so you rarely have to think about it. You'll dig into that trade-off in detail in the next lesson.

Big Picture

Two alternative paths exist to this default JIT pipeline, and you'll meet them properly in a later module — for now, just know they exist:

How It Works

Step 1 — You write and build C#

public static int Square(int n) => n * n;

When you run dotnet build, Roslyn parses this into a syntax tree, resolves every symbol (what is n? what type does * mean here?), and checks it against the language rules. This is where compile errors like "cannot convert type" get caught — before your program ever runs.

Step 2 — Roslyn emits IL and metadata

Roslyn lowers your C# into IL, a stack-based, CPU-independent instruction set. The Square method above becomes something like:

IL_0000: ldarg.0
IL_0001: ldarg.0
IL_0002: mul
IL_0003: ret

Alongside the IL, Roslyn writes metadata — a structured catalog of every type, method signature, field, and attribute in the assembly. This metadata is what lets tools like reflection, the debugger, and IntelliSense understand your code's shape without re-parsing C# source.

Step 3 — The assembly is packaged

IL and metadata are packaged into a Portable Executable (PE) file — your familiar .dll or .exe. This file contains no CPU-specific instructions at all yet. The same assembly can, in principle, run on an x64 Windows server or an Arm64 Linux container without recompilation, as long as a compatible .NET runtime is present.

Step 4 — You run the program, and the CLR takes over

When you (or your hosting environment) launch the app, the dotnet host starts the CLR, which loads the entry assembly, resolves its dependencies, and prepares to run Main. No machine code has been generated yet — only IL has been loaded.

Step 5 — The JIT compiles methods on first call

The very first time Square is actually invoked, the CLR notices it has no native code for it yet, and hands the IL to the JIT compiler. By default, the JIT produces a Tier 0 version first: quick to generate, with minimal optimization. If Square turns out to be called repeatedly (it's "hot"), the runtime schedules a background recompilation to a fully optimized Tier 1 version, and future calls use that instead. Methods called only once or twice may simply stay at Tier 0 forever — spending optimization effort on them wouldn't pay off.

Step 6 — The CPU executes native code

Only now does actual machine code run — real x64 or Arm64 instructions, sitting in memory, executed directly by the processor. Everything before this step was preparation; this is the only step the hardware itself participates in.

Simple Example

Consider this tiny console app:

int total = 0;
for (int i = 0; i < 1_000_000; i++)
{
    total += Square(i);
}
Console.WriteLine(total);

static int Square(int n) => n * n;

Code → What happens:

• Main is JIT-compiled at Tier 0 the moment the process starts and Main is first invoked by the runtime.
• Square is JIT-compiled at Tier 0 the very first time the loop calls it (iteration 0).
• After roughly 30 calls (the exact threshold is a runtime implementation detail, not a documented contract you should code against), the runtime notices Square is hot and queues it for Tier 1 recompilation on a background thread.
• A moment later, calls to Square transparently start using the new, fully optimized Tier 1 code — likely with the multiplication inlined directly into the loop, eliminating the call overhead entirely.
• You never see any of this. It's invisible from C# — no code you write triggers or observes tiering directly.

Real-World Example

Picture an ASP.NET Core API deployed as a container that autoscales — new instances spin up in response to traffic spikes, run for a while, and then get torn down.

• When a new container starts, the CLR loads all the assemblies, and the JIT has to compile Main, the ASP.NET Core middleware pipeline, routing, and your controllers — all before the first request can be handled. This is exactly why Tier 0 exists: it gets that first request served quickly instead of making the pod wait through full optimization of hundreds of startup-path methods.
• Once the container is warm and serving thousands of requests per second, the handful of hot-path methods (JSON serialization, your busiest endpoint handler, a frequently-hit database query builder) get promoted to Tier 1, so steady-state throughput is just as good as if everything had been optimized from the start.
• If this same API is deployed as a serverless function that only lives for a few requests before being recycled, the container may never live long enough for Tier 1 to matter — which is exactly the scenario where teams reach for ReadyToRun or NativeAOT to skip JIT warm-up entirely.

Analogy

Under the Hood

Common Confusion

1. "C# is a compiled language" — yes, but compiled twice

C# is neither "purely compiled" like C, nor "purely interpreted" like classic scripting languages. It's compiled ahead of time to IL (portable, but not directly runnable by hardware) and then compiled again, just-in-time, to native code. Calling it "interpreted" is wrong — the JIT genuinely produces real machine code, it just does so lazily and at run time rather than in advance.

2. "JIT compilation happens once, for the whole app, at startup"

It does not. JIT compilation is per method and lazy — a method is compiled the first time it's actually called, not when the assembly is loaded. A method your program never calls in a given run is never JIT-compiled at all. This is why cold-start profiles for large apps show JIT activity spread across the first several seconds (or longer), not concentrated in a single "startup compile" moment.

3. "ReadyToRun and NativeAOT are the same thing"

They solve a similar problem (slow JIT warm-up) very differently. R2R assemblies still carry IL and still run on the full CLR — the pre-compiled native code is just an optional fast-path the runtime can use instead of JIT-ing from scratch, and the JIT can still re-optimize hot R2R methods later. NativeAOT produces a single native executable with no IL, no JIT, and no separate CLR loading step at run time — it's a fundamentally different deployment model, covered in full later in this book.

Common Mistakes

Mistake 1 — Benchmarking a method's first call

Timing a method's very first invocation and concluding "this code is slow" — you likely measured Tier 0 JIT compilation time plus Tier 0 (unoptimized) execution, not steady-state performance.

Warm up the method with a few throwaway calls before timing it, or use a proper benchmarking tool (like BenchmarkDotNet) that accounts for JIT warm-up automatically.

Mistake 2 — Assuming the same IL always produces identical native code

Believing that because two machines run "the exact same DLL," they run identical machine instructions.

The JIT generates native code tailored to the actual CPU it's running on (available instruction set extensions, cache sizes considered by the optimizer, etc.). The IL is identical; the resulting native code can legitimately differ between machines.

Mistake 3 — Reaching for NativeAOT to "fix" every startup problem

Jumping straight to NativeAOT the moment cold start feels slow, without checking whether ReadyToRun or simply reducing startup-path work would be enough.

NativeAOT gives up some dynamic capabilities (heavy runtime reflection, certain plugin-loading patterns). Understand the trade-off — covered fully in its own lesson — before committing your deployment model to it.

Why Does This Matter for My Code?

You don't "turn on" this pipeline — it's always running underneath every C# program. But understanding it changes how you reason about real problems:

• Diagnosing cold-start latency in containers, serverless functions, or CLI tools — you now know to ask "how much of this is JIT warm-up?" before assuming it's your code's fault.
• Writing fair benchmarks — you know steady-state (Tier 1) performance and first-call (Tier 0) performance are genuinely different numbers, and both can matter depending on your scenario.
• Choosing a deployment model — long-running services (most APIs) benefit most from the default tiered JIT; short-lived, scale-to-zero workloads may benefit from ReadyToRun or NativeAOT.
• Understanding the rest of this book — garbage collection, memory allocation, and boxing all happen while native code runs. This lesson is the map that shows where that native code came from.

Mental Model

Key Takeaway

Check Your Understanding

You've traced the full journey from C# source to executing machine code. Let's check that the mental model is solid before building on it.

You now understand the pipeline that turns your C# into running machine code — the foundation for everything the CLR does next.