Comment le code C# s'exécute-t-il (IL, JIT, AOT) ?

Question

Accepted Answer

C# ne compile pas directement en code machine. Il compile en **IL** (Intermediate Language) — un bytecode indépendant de la plateforme — que le **CLR** exécute, en utilisant la compilation **JIT** (Just-In-Time) pour traduire l'IL en code machine natif au moment de l'exécution. **AOT** (Ahead-Of-Time) est une alternative qui compile en code natif au moment de la construction.

## Le pipeline d'exécution

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

Le compilateur C# produit **IL** (un bytecode indépendant du CPU), emballé dans un assembly. Au moment de l'exécution, le **CLR** (Common Language Runtime) utilise le **compilateur JIT** pour traduire les méthodes IL en code machine natif lors de leur premier appel — et le code natif est mis en cache pour les appels suivants.

## Pourquoi IL + JIT ? Avantages

```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 offre l'indépendance de plateforme (un assembly, n'importe quelle plateforme avec un runtime) et permet au JIT d'optimiser pour le matériel spécifique. (Il y a un coût de démarrage car les méthodes sont compilées en JIT lors du premier usage.)

## AOT — Compilation Ahead-Of-Time

```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** compile en code natif au moment de la construction — éliminant le coût de démarrage du JIT (démarrage plus rapide, plus petit, moins de mémoire), précieux pour le serverless et les CLI, au prix d'une certaine flexibilité.

## Pourquoi c'est important

Comprendre comment le code C# s'exécute — le pipeline **IL → JIT → natif** — est une connaissance précieuse pour comprendre profondément la plateforme .NET, expliquer ses capacités et prendre des décisions éclairées sur le déploiement et la performance.

L'idée clé est que C# compile en **IL** (bytecode indépendant de la plateforme) plutôt qu'en code natif, et le **CLR** utilise la compilation **JIT** pour le traduire en code natif au moment de l'exécution — c'est ce qui permet l'indépendance de plateforme de .NET (le même assembly compilé s'exécute n'importe où avec un runtime), l'optimisation au moment de l'exécution (le JIT optimise pour le matériel réel) et l'interopérabilité des langages (C#, F#, VB compilent tous en IL).

Cela explique des comportements comme le coût de démarrage/warm-up du JIT (pertinent lors de la création de benchmarks ou de l'optimisation du démarrage).

Comprendre **AOT** (Native AOT, une alternative moderne compilant en code natif au moment de la construction) est de plus en plus important pour des scénarios spécifiques : elle offre un **démarrage plus rapide, des déploiements plus petits et une mémoire réduite** (précieux pour les fonctions serverless, les outils CLI et les conteneurs où le temps de démarrage et la taille importent), au prix de l'optimisation JIT au moment de l'exécution et de certaines limitations de réflexion/dynamique — donc connaître le compromis JIT-vs-AOT vous aide à choisir la bonne approche pour une cible de déploiement.

Bien que ce soit plus une connaissance conceptuelle que du coding au quotidien, comprendre le modèle d'exécution (IL/JIT/AOT) est précieux pour expliquer comment .NET réalise l'indépendance de plateforme et la performance, pour raisonner sur la performance de démarrage, et pour prendre des décisions de déploiement (en particulier la pertinence croissante d'AOT pour les scénarios cloud-natifs) — ce qui en fait une connaissance de haut niveau digne d'intérêt qui démontre une compréhension profonde de la plateforme .NET et un sujet pertinent pour les discussions axées sur la performance et le déploiement.