How does IL become machine code at run time, including how generic methods are compiled for reference and value types?

How I would answer this in an interview

IL becomes machine code lazily, per method: each method starts with a small stub; on the first call the runtime asks the JIT to compile it (or finds precompiled ReadyToRun code), then patches the entry so later calls go straight to native code. For generic methods, the runtime decides between shared code for reference-type instantiations and specialised code for each value-type instantiation — the key to understanding generic performance.

1. Method descriptors and precode

For each method, the runtime keeps a MethodDesc (metadata pointer, flags, entry point). Initially the entry point is a precode/prestub:

caller --call--> [precode] --first time--> ThePreStub -> runtime -> JIT compile -> backpatch entry
         later:  [precode/slot] ------------------------------------------------> native code

1. The caller calls through an indirection (a vtable slot for virtual methods, a precode or indirection cell for others).
2. First call lands in ThePreStub, which identifies the method, checks for R2R code, or invokes the JIT.
3. The JIT compiles IL to native code with GC info, unwind info and debug info.
4. The runtime backpatches the precode/slot so future calls go directly to the native code (and with tiering, later to a newer Tier 1 version).

Type loading happens alongside: before compiling a method, the types it touches must be loaded (MethodTables built), static constructors may need to run (or checks inserted), and string literals interned.

2. What the JIT produces

• Machine code for the specific CPU (feature detection at start-up, e.g. AVX2/AVX-512, Arm64 extensions).
• GC info: which registers/stack slots hold object references at each safe point.
• EH info: exception handling regions.
• Unwind info: for stack walking.
• Code is stored in the code heap; method entry points updated.

3. Generic methods: shared vs specialised code

public static T Max<T>(T a, T b) where T : IComparable<T> => a.CompareTo(b) >= 0 ? a : b;

Max(1, 2);                    // T = int
Max(1.5, 2.5);                // T = double
Max("a", "b");                // T = string
Max(customerA, customerB);    // T = Customer (class)

Value-type instantiations (int, double, any struct): the JIT compiles a separate specialised body per type. T is known exactly, so:

• a.CompareTo(b) is a direct call on the struct (no boxing), often inlined,
• sizes and layouts are known,
• typeof(T) == typeof(int) checks fold to constants.

Reference-type instantiations (string, Customer, any class): the JIT compiles one shared body using a canonical placeholder __Canon (all references look the same to the machine code — pointer-sized, GC-tracked). Type-specific information needed at run time (for casts, typeof(T), new T[], statics, constrained calls) comes from a generic dictionary:

• For instance methods of generic classes → reached via the object's MethodTable.
• For generic methods and static methods → passed as a hidden instantiation argument.

So Max<string> and Max<Customer> run the same machine code, with CompareTo dispatched through the interface (with the dictionary supplying type info). Shared code saves JIT time and memory; specialised code maximises speed.

4. Consequences

• Generic collections of value types (List<int>, Dictionary<Guid, T>) are fast — specialised, no boxing.
• Generic math over structs compiles to the same code as hand-written loops.
• Many value-type instantiations increase code size/JIT time (and NativeAOT binary size).
• Shared generic code has small extra costs for dictionary lookups and can't specialise on T (e.g. typeof(T) branches remain).
• Generic virtual methods need runtime lookup of the right instantiation per call — slower.
• ReadyToRun can't always precompile cross-assembly generic instantiations; some are JIT-ed at start-up.

5. A production example

A high-throughput event processor used Dictionary<EventKey, Stats> where EventKey was a class. Changing it to a readonly record struct made the dictionary's methods specialised for the key type (no virtual Equals/GetHashCode calls via shared code, no per-key allocation), improving lookup throughput by ~30%. Conversely, a generic Serializer<T> instantiated for ~200 different struct DTOs inflated JIT time at start-up; making those DTOs classes (shared code) cut start-up JIT time, since that path wasn't hot.