What actually happens between writing C# source code and the CPU executing it?

1. The stages, drawn out

  Program.cs
      |  Roslyn (dotnet build)
      v
  MyApp.dll  = IL + metadata + manifest
      |  host (dotnet / apphost) reads runtimeconfig.json, loads CoreCLR
      v
  CLR: assembly loader -> type loader -> method stubs
      |  first call of a method
      v
  RyuJIT: IL -> native code (Tier 0)
      |  hot method (call counting, loops via OSR)
      v
  RyuJIT again: optimised native code (Tier 1, with Dynamic PGO data)
      |
      v
  CPU: fetch -> decode -> execute, using registers, caches, RAM

2. What IL looks like

For static int Add(int a, int b) => a + b; Roslyn emits roughly:

ldarg.0   // push a
ldarg.1   // push b
add       // pop two, push the sum
ret       // return top of stack

IL is a stack machine. Real CPUs are register machines, so the JIT's main job is to map the evaluation stack onto CPU registers. On x64, the optimised result is often just:

lea eax, [rcx+rdx]
ret

3. Tiered compilation in detail

Methods with loops used to skip Tier 0; since .NET 7, OSR lets them start at Tier 0 too. You can switch tiering off with <TieredCompilation>false</TieredCompilation> or the DOTNET_TieredCompilation=0 environment variable, which is mainly useful for benchmarking experiments.

4. ReadyToRun versus Native AOT

• ReadyToRun code is precompiled but less optimised (it can't assume the exact CPU or inline across version bubbles). Hot methods are still re-JIT-compiled at Tier 1.
• Native AOT removes the JIT entirely. The app can't generate code at run time, so features that depend on it (some reflection patterns, Reflection.Emit, dynamic assembly loading) don't work. The compiler warns about this with trimming and AOT analysers.

5. How the OS and CPU take over

1. The OS creates a process with its own virtual address space.
2. The loader maps the executable and libraries into that space; pages are loaded lazily on page faults.
3. The OS creates the main thread and the scheduler puts it on a core.
4. The CPU's instruction pointer moves through machine code: each instruction is fetched (from L1i cache if possible), decoded into micro-operations, and executed.
5. JIT-compiled code lives in memory pages marked executable; the CPU doesn't care whether code came from disk or from the JIT.

6. Why this matters in interviews and production

• Cold start: JIT work is real CPU time. Serverless and scale-out scenarios care about it.
• Benchmarks: never time the first call; it includes JIT. BenchmarkDotNet runs warm-up iterations for this reason.
• Diagnostics: stack traces show IL-level methods, but performance depends on the generated machine code (inlining, bounds-check elimination, devirtualisation).

7. Try it yourself

1. Write a small Add method, build it, and open the .dll in ILSpy to see the IL.
2. Paste the same code into sharplab.io and switch the output to JIT Asm to see the x64 machine code.
3. On .NET 8 or later, run your app with DOTNET_JitDisasm=Add and look at the assembly printed to the console, once for Tier 0 and once for Tier 1 after calling it in a loop.
4. Publish the same app with -p:PublishReadyToRun=true and then with -p:PublishAot=true, and compare start-up time and output size.

namespace HowCodeRuns;

using System.Diagnostics;
using System.Runtime.CompilerServices;

public static class Program
{
    public static void Main()
    {
        // First call: includes JIT compilation of Add (Tier 0).
        var sw = Stopwatch.StartNew();
        Add(1, 2);
        Console.WriteLine($"First call: {sw.Elapsed.TotalMicroseconds:F1} µs");

        // Call it many times so tiered compilation promotes it to Tier 1.
        long total = 0;
        for (var i = 0; i < 1_000_000; i++)
        {
            total += Add(i, 1);
        }

        sw.Restart();
        Add(1, 2);
        Console.WriteLine($"Warm call: {sw.Elapsed.TotalMicroseconds:F3} µs (total {total})");
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static int Add(int a, int b) => a + b;
}

# Print the machine code the JIT generates for Add (.NET 7+)
DOTNET_JitDisasm=Add dotnet run -c Release

# Compare publish modes
dotnet publish -c Release -r linux-x64 -p:PublishReadyToRun=true
dotnet publish -c Release -r linux-x64 -p:PublishAot=true