CLR (Runtime) Study Portal

A: The Common Language Runtime is the execution engine of .NET: the component that takes compiled .NET code and runs it, managing memory, types, threads and errors on the program's behalf. Code that runs under its control is called managed code; ordinary native code (C, C++, the OS) is unmanaged. It is Microsoft's implementation of the CLI (Common Language Infrastructure), an ECMA/ISO standard (ECMA-335) that defines IL, metadata and the type system, so other runtimes (such as Mono) can run the same assemblies.

A:

A:

A:

static int Add(int a, int b) => a + b;

// IL produced by the compiler
// ldarg.0      push a
// ldarg.1      push b
// add          pop both, push a + b
// ret

// x64 native code produced by the JIT at first call
// lea eax, [rcx+rdx]
// ret

You can see IL with ILSpy, dotPeek, or ildasm, and the JIT's output with SharpLab or DOTNET_JitDisasm.

A: One assembly runs on any OS and CPU with a runtime (x64, Arm64, Windows, Linux, macOS). The JIT can optimize for the actual machine (for example using AVX-512 if the CPU has it) and for actual runtime behaviour (see dynamic PGO). Rich metadata enables reflection, serialization, debugging and verification. And every .NET language targets the same IL, so they interoperate.

A: Since .NET Core 3.0, a method is first compiled quickly with few optimizations (tier 0) so the app starts fast. The runtime counts calls; once a method is hot (about 30 calls, then a short delay), it is recompiled in the background with full optimizations (tier 1) and the call site is switched over. On-stack replacement (OSR, .NET 7) lets a long-running loop inside a tier-0 method jump to optimized code without waiting for the next call.

A: Profile-guided optimization at runtime, on by default since .NET 8. While code runs at an instrumented tier, the runtime records which types actually flow through virtual and interface calls and delegate invocations, and which branches are taken. The tier-1 compile uses that data: for example, if an IComparer<T> call almost always sees one class, the JIT adds a type check and inlines that class's method directly (guarded devirtualization). It makes idiomatic abstraction-heavy code noticeably faster without code changes.

A:

A: The CLR's single type model shared by all .NET languages: classes, structs, interfaces, enums, delegates, the rules for inheritance, visibility, value vs reference semantics and so on. int in C#, Integer in VB and int in F# are all the CTS type System.Int32. The CLS (Common Language Specification) is a subset of rules (for example, no public unsigned types, no names that differ only by case) that a library follows if it wants to be usable from every .NET language.

A: Every reference-type object starts with two pointer-sized fields before its data (on 64-bit, 16 bytes):

The MethodTable is a per-type structure built at type load: base type, implemented interfaces, the virtual method table (slots pointing at native code for each virtual method), field layout and size, and a pointer to static data. obj.GetType(), is/as casts and virtual calls all go through it. A value type (struct) stored inline has neither header nor MethodTable pointer, which is why it is compact but has to be boxed (copied into a new heap object with both) when treated as object or an interface.

 variable (stack)       managed heap                     type data (loader heap)
┌────────────┐       ┌───────────────────────┐        ┌───────────────────────────┐
│ ref ───────┼─────► │ object header    8 B  │        │ MethodTable for Order     │
└────────────┘       │ MethodTable ptr  8 B ─┼──────► │  base type, interfaces    │
                     │ Id        (int)  4 B  │        │  vtable: ToString → code  │
                     │ Total (decimal) 16 B  │        │  field layout, size       │
                     └───────────────────────┘        │  statics                  │
                                                      └───────────────────────────┘

A: Generics are reified: List<int> and List<string> are distinct runtime types with their own MethodTables (unlike Java's type erasure). For value-type arguments the JIT generates specialized native code per type (List<int>, List<double>), so there is no boxing and code is as fast as hand-written. For reference-type arguments the native code is shared (all references are the same size), using a hidden type-context parameter where the exact type is needed. That is why List<int> avoids boxing and why generic value-type code can be as fast as non-generic code.

A:

A: It is a generational, tracing, compacting collector. It starts from roots (static fields, locals and arguments on thread stacks, CPU registers, GC handles), marks every object reachable from them, and reclaims the rest; surviving objects are compacted (moved together) and references are updated. Most objects die young, so gen0 is collected often and cheaply; objects that survive are promoted to gen1 and gen2. Details (server vs workstation GC, LOH, finalization, tuning) are in the "CLR & Garbage Collector (GC)" note in Core C#.

A: Managed code can only access memory through correctly typed references: casts are checked, array accesses are bounds-checked, fields are accessed at known offsets, and there is no pointer arithmetic outside unsafe code. So one bug cannot silently corrupt unrelated memory the way a buffer overflow in C can. The JIT removes checks it can prove unnecessary (for example, bounds checks in a for (i = 0; i < arr.Length; i++) loop).

A: The JIT usually does not emit an explicit null check. Dereferencing null makes the CPU read address 0 (plus a small offset), which the OS rejects with an access violation / segmentation fault; the CLR's handler sees that the fault came from managed code near address 0 and converts it into a NullReferenceException. It is a free check in the common, non-null case.

A: Exceptions are objects deriving from System.Exception. When one is thrown, the runtime does a first pass up the call stack to find a matching catch (running when filters, which is why filters run before any finally), then a second pass that unwinds the stack, running finally blocks, until it reaches the handler. Throwing is expensive (stack-trace capture, two passes), which is why exceptions are for exceptional cases and not control flow. An unhandled exception on any thread terminates the process.

A: Yes. Each managed Thread maps 1:1 to an OS thread, with the CLR adding managed state (culture, execution context, GC information). The thread pool manages a set of worker threads and I/O completion threads, grows and shrinks them based on load, and runs Task work and await continuations. The GC must bring managed threads to a safe point (where it knows exactly which slots hold references) before it can move objects.

A: An assembly is the unit of deployment and versioning: a PE file (.dll/.exe) containing a manifest (name, version, culture, public key, referenced assemblies), metadata tables (every type, method, field, attribute) and IL. The CLR uses metadata to lay out types, resolve method calls, check accessibility, support reflection and attributes, and let the debugger map native code back to source.

A: .NET Framework used AppDomains to isolate and unload code within one process. .NET Core+ supports only one AppDomain; isolation of loading is done with AssemblyLoadContext, which can load different versions of the same assembly side by side (plugins) and can be collectible so the loaded code and types can be unloaded. For real security isolation, use separate processes or containers.

A: Through P/Invoke: a static extern method marked [DllImport] or, since .NET 7, [LibraryImport] (source-generated marshalling, which also works with Native AOT). The CLR loads the native library, converts arguments between managed and native representations (marshalling: strings, structs, arrays), transitions the thread to "preemptive" mode so the GC can run while native code executes, and pins any managed memory handed to native code so the GC does not move it.

A:

A: Compiled twice: C# is compiled to IL ahead of time by Roslyn, and IL is compiled to native code by the JIT at runtime (or ahead of time with ReadyToRun or Native AOT). The CLR does not interpret IL in normal execution.

A: The first call includes JIT compilation of that method (and possibly loading its types and running static constructors). Later calls go straight to native code, and hot methods are recompiled at tier 1 with full optimizations. Warm-up effects like this are why benchmarks use BenchmarkDotNet, which runs warm-up iterations.

A: No. Memory is reclaimed at some point after the object becomes unreachable, when the GC decides to run. Deterministic cleanup of non-memory resources (files, sockets, connections) is done with IDisposable and using, not by the GC.

A: Managed memory is allocated by the CLR on the managed heap and freed by the GC. Unmanaged memory is allocated outside the GC's control (native libraries, Marshal.AllocHGlobal, OS handles) and must be released explicitly, typically in Dispose backed by a SafeHandle.