Hvordan udføres C#-kode (IL, JIT, AOT)?

Question

Accepted Answer

C# kompileres ikke direkte til maskinkode. Det kompileres til **IL** (Intermediate Language) — en platformuafhængig bytecode — som **CLR** kører, ved brug af **JIT** (Just-In-Time) kompilering for at oversætte IL til oprindelig maskinkode ved kørselstid. **AOT** (Ahead-Of-Time) er et alternativ, der kompilerer til oprindelig kode på build-tid.

## Eksekveringspipelinen

```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
```

C#-kompilatoren producerer **IL** (en CPU-uafhængig bytecode), pakket i et assembly. Ved kørselstid bruger **CLR** (Common Language Runtime) **JIT-kompilatoren** til at oversætte IL-metoder til oprindelig maskinkode, når de først kaldes — og den oprindelige kode cachet til senere opkald.

## Hvorfor IL + JIT? Fordele

```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 giver platformuafhængighed (ét assembly, enhver platform med en runtime) og lader JIT optimere til den specifikke hardware. (Der er en opstartsomkostning, da metoder JIT-kompileres ved første brug.)

## AOT — Ahead-Of-Time kompilering

```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** kompilerer til oprindelig kode på build-tid — hvilket eliminerer JIT-opstartsomkostningen (hurtigere opstart, mindre størrelse, mindre hukommelse), værdifuldt for serverless og CLI'er, på bekostning af noget fleksibilitet.

## Hvorfor det betyder noget

At forstå, hvordan C#-kode udføres — **IL → JIT → oprindelig** pipeline — er værdifuld viden for at forstå .NET-platformen dybt, forklare dens kapaciteter og træffe informerede beslutninger om udrulning og ydeevne.

Nøgleindsigten er, at C# kompileres til **IL** (platformuafhængig bytecode) snarere end oprindelig kode, og **CLR** bruger **JIT-kompilering** til at oversætte den til oprindelig kode ved kørselstid — hvilket er det, der aktiverer .NET's platformuafhængighed (samme kompileret assembly kører hvor som helst med en runtime), kørselstidsoptimering (JIT optimerer til den faktiske hardware) og sprogokompatibilitet (C#, F#, VB kompilerer alt til IL).

Dette forklarer adfærd som JIT opstart/opvarmningsomkostningen (relevant ved benchmarking eller optimering af opstart).

At forstå **AOT** (Native AOT, et moderne alternativ som kompilerer til oprindelig kode på build-tid) bliver stadig vigtigere for specifikke scenarier: det giver **hurtigere opstart, mindre udrulninger og lavere hukommelse** (værdifuldt for serverless-funktioner, CLI-værktøjer og containere, hvor opstartstid og størrelse betyder noget), på bekostning af kørselstids-JIT-optimering og nogle reflection/dynamiske begrænsninger — så at kende JIT-vs-AOT-afvejlingen hjælper dig med at vælge den rigtige tilgang til et udrulningsmål.

Selvom dette er mere konceptuelt end daglig kodning, er det værdifuldt at forstå eksekveringsmodellen (IL/JIT/AOT) for at forklare, hvordan .NET opnår platformuafhængighed og ydeevne, for at ræsonnere om opstartsydeevne og for at træffe udrulningsbeslutninger (især den voksende relevans af AOT til cloud-native scenarier) — hvilket gør det til værdifuld viden på seniorniveau, der demonstrerer dyb forståelse af .NET-platformen og er et relevant emne til ydeevne- og udrulningsfokuserede diskussioner.