C# 代码如何变成机器码编译与执行全链路系列C#与常用数据结构源码剖析 · 运行时底层剖析阅读时间约 45 分钟前置知识C# 基本语法、IL 基础概念一、引言当你在 IDE 中敲下var list new Listint()并按下 F5 时这行代码经历了一段漫长的旅程才能变成 CPU 能理解的机器指令。这段旅程至少穿越四个关键站点Roslyn 编译器C# → IL、CLR 加载器IL → 运行时类型、JIT/AOT 编译器IL → 机器码、以及运行时执行引擎机器码 GC 异常处理。对于理解数据结构的行为而言这个全链路的重要性怎么强调都不为过。比如你写了一个struct Enumerator来避免 foreach 的 GC 分配——这个优化是否生效取决于 JIT 是否对枚举器做了去虚拟化。你在 IL2CPP 下使用dynamic关键字——它会直接报错因为 AOT 编译根本不可能生成动态代码。本篇文章是这个专栏的地基——在深入每一个数据结构的源码之前我们需要先建立代码如何运行的完整心智模型。我们将从编译器前端一路追踪到 CPU 执行单元并在每个阶段标注关键源码位置方便后续深入查阅。二、第一阶段Roslyn 编译器——从 C# 到 IL2.1 Roslyn 的架构设计Roslyn 是 .NET 的编译器即服务Compiler-as-a-Service实现。与传统的黑盒编译器不同Roslyn 将编译过程的每个阶段都暴露为公开 API使得 IDE 的智能提示、代码分析器、重构工具可以直接使用编译器的内部数据。Roslyn 的编译流水线分为四个核心阶段语法分析Parser将源代码文本解析为一棵语法树SyntaxTree。每个 token关键字、标识符、运算符、字面量被分类为SyntaxToken并按语法规则组织为SyntaxNode树。例如var x 1 2;会被解析为LocalDeclarationStatementSyntax节点其子节点包括EqualsValueClauseSyntax和BinaryExpressionSyntax。语义分析Binder在语法树的基础上构建语义模型SemanticModel。这个阶段进行符号解析x是什么类型的变量List是指哪个命名空间中的类、类型检查、重载决议。SemanticModel 回答了这段代码是什么意思的问题。绑定与 Lowering将语法树转换为BoundTree——一个更接近 IL 的中间表示。在这个阶段高级语法糖被降级为更基础的表达形式。例如using语句被展开为try-finallyforeach被转换为while 枚举器模式async方法被重写为状态机类。IL 发射Emit将 BoundTree 转换为 IL 字节码并写入 PEPortable Executable格式的 .dll 或 .exe 文件。同时写入完整的元数据表Metadata Tables——包括类型定义TypeDef、方法定义MethodDef、字段定义FieldDef等。2.2 实战从语法树到 IL 的亲眼见证我们以一个最简单的Listint.Add调用为例var list new Listint(); list.Add(42);在 Roslyn 的 Syntax Visualizer 中list.Add(42)这行会被解析为InvocationExpressionSyntax ├── MemberAccessExpressionSyntax │ ├── IdentifierNameSyntax list │ └── IdentifierNameSyntax Add └── ArgumentListSyntax └── ArgumentSyntax └── NumericLiteralExpressionSyntax 42经语义分析后编译器知道list是Listint类型Add是ListT.Add(T)方法42作为int参数。最终发射的 IL 大致为// new Listint() newobj instance void class [System.Collections]System.Collections.Generic.List1int32::.ctor() stloc.0 // 存储到局部变量 0 // list.Add(42) ldloc.0 // 加载 list ldc.i4.s 42 // 加载常量 42 callvirt instance void class [System.Collections]System.Collections.Generic.List1int32::Add(!0)注意几个关键细节newobj指令负责在托管堆上分配对象调用 GC 的分配器并调用构造函数stloc.0将栈顶的值存储到局部变量槽位 0callvirt用于虚方法调用即使Add不是虚方法对于引用类型的实例方法编译器也使用callvirt——因为它附带空引用检查!0是泛型参数占位符表示ListT的第一个类型参数即int2.3 程序集的结构编译产物是一个 PE 格式的文件。其内部结构如下PE Header ├── CLI Header ├── Metadata Tables │ ├── Module (0x00) │ ├── TypeDef (0x02) ← 你定义的每个类 │ ├── MethodDef (0x06) ← 每个方法的签名 │ ├── FieldDef (0x04) ← 每个字段 │ ├── MemberRef (0x0A) ← 引用的外部类型/方法 │ └── TypeRef (0x01) ← 引用的外部类型 ├── IL Code Stream └── Resources元数据表存储了程序集中所有类型的完整描述。当 JIT 编译器需要知道一个方法的参数类型、一个字段的偏移量、或者一个类的继承链时都是通过查询这些元数据表获得的。2.4 编译器源码位置如果你想深入 Roslyn 的源码核心入口在C# 编译器前端dotnet/roslyn/src/Compilers/CSharp/Portable/Parser/— 语法分析器Binder/— 语义绑定器BoundTree/— 绑定树节点定义CodeGen/— IL 发射器编译入口点CSharpCompilation.Create()→CompileAndEmit()→Emit()三、第二阶段运行时加载——从 PE 文件到运行时类型3.1 CLR 加载器的工作流程当 .NET 运行时首次遇到一个类型引用时例如 JIT 编译某个方法时发现它调用了Listint加载器被触发Assembly 加载Assembly.Load()根据程序集名称查找并加载 PE 文件。对于强命名程序集会进行版本校验和签名验证。CoreCLR 使用AssemblyLoadContext来隔离不同上下文的程序集加载。Module 解析每个程序集包含一个或多个 Module通常只有一个。Module 是元数据的作用域。CLR 创建内部数据结构Module对象来持有元数据表。类型加载TypeLoader这是最复杂的阶段。类型加载器采用分级加载策略——不是一次性加载所有信息而是按需、分步加载。具体机制将在下一篇文章类型加载器中详述。关键数据结构有MethodTable类型的运行时身份证存储 vtable、接口映射、GC 布局信息EEClass类型的冷数据只在类型加载和反射时使用MethodDesc方法的运行时表示包含入口点Entry Point指针方法入口点的建立对于每个方法CLR 会创建一个 stub一小段跳转代码这个 stub 在方法首次被调用前指向 JIT 编译器的入口。当方法被首次调用时stub 跳转到 JITJIT 编译完成后将 stub 更新为指向编译后的机器码——这就是首次调用触发 JIT的机制。3.2 类型的运行时层次结构TypeHandle (抽象) ├── MethodTable (普通类型、泛型闭合类型) │ ├── Parent MethodTable (父类型) │ ├── Interface Map (实现的接口) │ ├── VTable Slots (虚方法表) │ └── GC Layout Info └── TypeDesc (指针、byref、泛型参数变量) ├── ParamTypeDesc (T[], T, T*) ├── FunctionTypeDesc (delegate*) └── TypeVarTypeDesc (泛型方法中的 T)这个层次结构决定了所有类型相关的运行时操作——对象分配newobj需要知道对象大小、方法分派callvirt需要查 vtable、GC 扫描需要知道哪些字段是引用——都是通过 MethodTable 完成的。四、第三阶段JIT 编译——IL 到机器码4.1 JIT 的触发与接口JIT 编译的最典型触发场景是方法首次被调用。具体流程调用方执行call或callvirt指令目标方法的入口点Entry Point指向一个Precode StubPrecode Stub 调用 JIT 编译器的compileMethod()入口JIT 将 IL 编译为机器码写入可执行内存Precode Stub 被改写backpatch为指向新生成的机器码后续调用直接跳转到机器码不再经过 JITJIT 编译器与运行时之间通过两个接口交互ICorJitCompilerJIT 端运行时调用 JIT定义在src/coreclr/inc/corjit.hcompileMethod()核心入口接收 IL 字节码返回机器码ICorJitInfo运行时端JIT 回调运行时定义在src/coreclr/inc/corinfo.hgetMethodDefFromMethod()获取方法元数据getClassAttribs()获取类型属性getFieldOffset()获取字段在对象中的偏移量4.2 RyuJIT 的编译阶段概览现代 .NET 使用 RyuJIT 编译器。它的编译流水线分为前端、中端、后端三大阶段包含超过 20 个子阶段前端 (Frontend) ├── Importation : IL → GenTree IR ├── Inlining : 内联候选方法的 IR ├── Morph : 形态变换字段访问→指针算术 中端 (Middle-end) ├── SSA Construction : 构建静态单赋值形式 ├── Value Numbering : 值编号消除重复计算 ├── CSE : 公共子表达式消除 ├── Range Analysis : 范围分析推导数组索引范围 ├── Bounds Check Elim : 边界检查消除 ├── Loop Optimization : 循环优化克隆、展开、IV 优化 ├── Dead Store Elim : 死存储消除 后端 (Backend) ├── Rationalization : HIR → LIR线性化 ├── Lowering : 暴露控制流和寄存器需求 ├── Register Alloc : 线性扫描寄存器分配 └── Code Generation : 遍历 IR 生成机器码每个阶段的具体细节将在后续文章JIT 编译管线、JIT 优化全景中详细展开。这里先建立一个全局视图GenTree IR是贯穿整个 JIT 的核心数据结构。前端使用树形节点父-子链接后端使用线性节点prev-next 链接。内联Inlining是最有影响力的优化——将小方法的代码直接嵌入调用方消除调用开销并启用更多的跨方法优化。SSA静态单赋值是 JIT 分析的数据基础——每个变量只被赋值一次使得数据流分析变得精确。值编号Value Numbering将语义相同的表达式映射到同一个编号使得 CSE 能识别并消除冗余计算。4.3 源码位置JIT 编译器源码全部在dotnet/runtime/src/coreclr/jit/目录下文件内容compiler.cpp/compiler.hppCompiler 主类gentree.cpp/gentree.hGenTree IR 定义morph.cpp形态变换inline.cpp内联决策和实现ssa.cppSSA 构建valueNum.cpp值编号rangecheck.cpp范围分析和边界检查消除loopcloning.cpp/loopunroll.cpp循环优化rationalize.cppIR 理性化lower.cpp/lsra.cppLowering 和寄存器分配codegen*.cpp代码生成五、第四阶段AOT 编译——另一种执行路径5.1 为什么需要 AOTJIT 编译的优势在于可以利用运行时的实际类型信息做特化优化、可以动态生成代码。但它有两个致命弱点冷启动慢应用启动时需要编译大量代码需要运行时可写可执行内存iOS 等平台不允许 JITAOTAhead-of-Time编译在应用部署之前就将 IL 预编译为机器码解决了这两个问题——但代价是失去了 JIT 的灵活性。5.2 三种 AOT 方案.NET 生态中有三种主要的 AOT 方案ReadyToRunR2R发行版中包含预编译的机器码 IL作为回退运行时会利用 R2R 代码加速启动但仍可用 JIT 处理未预编译的方法需要 JIT 运行时仍然存在源码位置dotnet/runtime/src/coreclr/tools/crossgen2/NativeAOT将整个应用完全预编译为原生代码包含一个精简的运行时GC、异常处理、线程管理但没有 JIT不支持System.Reflection.Emit、Assembly.Load动态加载需要提前注册泛型实例化源码位置dotnet/runtime/src/coreclr/nativeaot/IL2CPPUnity 专用工作流C# → IL DLL → IL2CPP 转换器 → C 源码 → 平台 C 编译器 → Native泛型处理编译时分析代码引用为值类型泛型生成特化代码引用类型泛型使用共享代码对数据结构的直接影响缺失的泛型实例化会在运行时抛MissingMethodExceptionIL2CPP 本身的源码属于 Unity 的专有技术不完全开源5.3 AOT 对数据结构的限制AOT 编译下以下与数据结构相关的特性受到限制特性JITAOT (NativeAOT/IL2CPP)dynamic关键字✅ 运行时动态绑定❌ 需要 JIT 编译器Reflection.Emit✅❌ 完全不可用MakeGenericMethod(typeof(X))✅⚠️ 仅限已注册的类型Assembly.Load✅❌ 不支持动态程序集ListMyStruct✅ 运行时 JIT 特化⚠️ 需在编译期确定六、机器码执行时的运行时服务编译得到的机器码不是孤立运行的。它在每一步执行中都得到运行时的服务6.1 GC 的协作JIT 编译器生成的机器码中嵌入了GC 信息GC Info哪些寄存器/栈位置在代码的哪个点持有活动 GC 引用GC 安全点Safe Point可以安全暂停线程进行 GC 的代码位置写屏障Write Barrier当引用字段被赋值时JIT 在赋值指令后插入写屏障代码——标记跨代引用的卡表Card Table写屏障是 GC 高性能的关键。如果没有它每次 Minor GC仅回收 Gen0都需要扫描所有 Gen2 对象的引用——那将是灾难性的性能开销。有了写屏障GC 只需扫描卡表中标记的被修改过的内存页。6.2 异常处理C# 中的try-catch-finally在 IL 层面是通过受保护区域Protected Region表达的在机器码层面则映射到平台的展开表Unwind Table。当异常发生时运行时根据展开表找到对应的方法帧执行正确的 catch 或 finally 处理。6.3 空引用检查C# 中访问空引用成员会抛出NullReferenceException。这不是编译器插入的显式检查——而是利用硬件的页面保护机制地址 0 附近的页面被标记为不可访问任何对空指针的解引用都会触发硬件异常Access Violation运行时捕获这个异常并转换为NullReferenceException。这个设计使得空引用检查几乎零性能开销。七、Unity 中的特殊编译链路Unity 开发者面对的是一个混合的编译世界7.1 编辑器模式[编辑器模式] C# 源码 → Roslyn → .NET DLL → Mono Runtime (JIT) ├── 编辑器中的脚本编译极快增量编译 ├── Play Mode 进入时无预编译等待 └── GC 使用 Boehm保守式非分代编辑器模式的体验很流畅脚本修改后几乎立即生效。但要注意编辑器中的 JIT 行为和真机的 AOT 行为可能有很大差异——某些在编辑器正常运行的功能如dynamic、Reflection.Emit在 IL2CPP 真机 build 中会直接崩溃。7.2 IL2CPP 构建模式[IL2CPP 构建模式] C# 源码 → Roslyn → .NET DLL → IL2CPP 转换器 → C 源码 → 平台 C 编译器 (Xcode/MSVC/Clang) → Native Binary ├── 构建时间长C 编译 链接 ├── 不支持 JIT 依赖特性dynamic、Reflection.Emit └── 泛型需要提前确定所有实例化Unity 6 的 C# 版本支持官方支持 C# 9.0编译器使用 RoslynAPI 兼容级别.NET Standard 2.1这意味着 C# 10/11/12 的新特性如全局 using、主构造函数、集合表达式、list patterns在 Unity 中默认不可用。但有部分特性可以通过手动配置csc.rsp文件来尝试启用——前提是它们不依赖新的运行时特性例如集合表达式需要 C# 12 的CollectionBuilderAttribute。八、关键源码索引下表汇总了本篇涉及的所有关键源码位置组件仓库关键路径Roslyn C# 编译器dotnet/roslynsrc/Compilers/CSharp/Portable/CoreCLR 运行时dotnet/runtimesrc/coreclr/vm/RyuJIT 编译器dotnet/runtimesrc/coreclr/jit/CoreCLR GCdotnet/runtimesrc/coreclr/gc/gc.cppNativeAOTdotnet/runtimesrc/coreclr/nativeaot/Mono 运行时dotnet/runtimesrc/mono/BOTR 架构文档dotnet/runtimedocs/design/coreclr/botr/Roslyn 架构文档dotnet/roslyndocs/compilers/CSharp/IL2CPP (Unity)Unity 内部非开源九、总结从var list new Listint()这行代码到 CPU 真正执行ListT.Add的机器码中间经历了Roslyn将它解析为语法树 → 绑定为语义模型 → 发射为 IL 字节码CLR 加载器将它注册为运行时类型创建 MethodTable 和 MethodDescJIT 编译器首次调用时将 IL 编译为最优机器码经过 20 个优化阶段或者AOT 编译器在构建期就将它预编译为机器码以牺牲灵活性换取启动速度运行时在执行时持续提供 GC 协作、异常处理和安全检查理解这个全链路就像打通了任督二脉。后续每一篇关于ListT扩容、Dictionary哈希碰撞、SpanT零分配的文章都会反复回到这个链路中的某个环节来解释为什么会这样设计和为什么性能是这样。下一篇MethodTable一切类型的运行时身份证 01-01-运行时-CSharp代码如何变成机器码-编译与执行全链路
C# 代码如何变成机器码编译与执行全链路系列C#与常用数据结构源码剖析 · 运行时底层剖析阅读时间约 45 分钟前置知识C# 基本语法、IL 基础概念一、引言当你在 IDE 中敲下var list new Listint()并按下 F5 时这行代码经历了一段漫长的旅程才能变成 CPU 能理解的机器指令。这段旅程至少穿越四个关键站点Roslyn 编译器C# → IL、CLR 加载器IL → 运行时类型、JIT/AOT 编译器IL → 机器码、以及运行时执行引擎机器码 GC 异常处理。对于理解数据结构的行为而言这个全链路的重要性怎么强调都不为过。比如你写了一个struct Enumerator来避免 foreach 的 GC 分配——这个优化是否生效取决于 JIT 是否对枚举器做了去虚拟化。你在 IL2CPP 下使用dynamic关键字——它会直接报错因为 AOT 编译根本不可能生成动态代码。本篇文章是这个专栏的地基——在深入每一个数据结构的源码之前我们需要先建立代码如何运行的完整心智模型。我们将从编译器前端一路追踪到 CPU 执行单元并在每个阶段标注关键源码位置方便后续深入查阅。二、第一阶段Roslyn 编译器——从 C# 到 IL2.1 Roslyn 的架构设计Roslyn 是 .NET 的编译器即服务Compiler-as-a-Service实现。与传统的黑盒编译器不同Roslyn 将编译过程的每个阶段都暴露为公开 API使得 IDE 的智能提示、代码分析器、重构工具可以直接使用编译器的内部数据。Roslyn 的编译流水线分为四个核心阶段语法分析Parser将源代码文本解析为一棵语法树SyntaxTree。每个 token关键字、标识符、运算符、字面量被分类为SyntaxToken并按语法规则组织为SyntaxNode树。例如var x 1 2;会被解析为LocalDeclarationStatementSyntax节点其子节点包括EqualsValueClauseSyntax和BinaryExpressionSyntax。语义分析Binder在语法树的基础上构建语义模型SemanticModel。这个阶段进行符号解析x是什么类型的变量List是指哪个命名空间中的类、类型检查、重载决议。SemanticModel 回答了这段代码是什么意思的问题。绑定与 Lowering将语法树转换为BoundTree——一个更接近 IL 的中间表示。在这个阶段高级语法糖被降级为更基础的表达形式。例如using语句被展开为try-finallyforeach被转换为while 枚举器模式async方法被重写为状态机类。IL 发射Emit将 BoundTree 转换为 IL 字节码并写入 PEPortable Executable格式的 .dll 或 .exe 文件。同时写入完整的元数据表Metadata Tables——包括类型定义TypeDef、方法定义MethodDef、字段定义FieldDef等。2.2 实战从语法树到 IL 的亲眼见证我们以一个最简单的Listint.Add调用为例var list new Listint(); list.Add(42);在 Roslyn 的 Syntax Visualizer 中list.Add(42)这行会被解析为InvocationExpressionSyntax ├── MemberAccessExpressionSyntax │ ├── IdentifierNameSyntax list │ └── IdentifierNameSyntax Add └── ArgumentListSyntax └── ArgumentSyntax └── NumericLiteralExpressionSyntax 42经语义分析后编译器知道list是Listint类型Add是ListT.Add(T)方法42作为int参数。最终发射的 IL 大致为// new Listint() newobj instance void class [System.Collections]System.Collections.Generic.List1int32::.ctor() stloc.0 // 存储到局部变量 0 // list.Add(42) ldloc.0 // 加载 list ldc.i4.s 42 // 加载常量 42 callvirt instance void class [System.Collections]System.Collections.Generic.List1int32::Add(!0)注意几个关键细节newobj指令负责在托管堆上分配对象调用 GC 的分配器并调用构造函数stloc.0将栈顶的值存储到局部变量槽位 0callvirt用于虚方法调用即使Add不是虚方法对于引用类型的实例方法编译器也使用callvirt——因为它附带空引用检查!0是泛型参数占位符表示ListT的第一个类型参数即int2.3 程序集的结构编译产物是一个 PE 格式的文件。其内部结构如下PE Header ├── CLI Header ├── Metadata Tables │ ├── Module (0x00) │ ├── TypeDef (0x02) ← 你定义的每个类 │ ├── MethodDef (0x06) ← 每个方法的签名 │ ├── FieldDef (0x04) ← 每个字段 │ ├── MemberRef (0x0A) ← 引用的外部类型/方法 │ └── TypeRef (0x01) ← 引用的外部类型 ├── IL Code Stream └── Resources元数据表存储了程序集中所有类型的完整描述。当 JIT 编译器需要知道一个方法的参数类型、一个字段的偏移量、或者一个类的继承链时都是通过查询这些元数据表获得的。2.4 编译器源码位置如果你想深入 Roslyn 的源码核心入口在C# 编译器前端dotnet/roslyn/src/Compilers/CSharp/Portable/Parser/— 语法分析器Binder/— 语义绑定器BoundTree/— 绑定树节点定义CodeGen/— IL 发射器编译入口点CSharpCompilation.Create()→CompileAndEmit()→Emit()三、第二阶段运行时加载——从 PE 文件到运行时类型3.1 CLR 加载器的工作流程当 .NET 运行时首次遇到一个类型引用时例如 JIT 编译某个方法时发现它调用了Listint加载器被触发Assembly 加载Assembly.Load()根据程序集名称查找并加载 PE 文件。对于强命名程序集会进行版本校验和签名验证。CoreCLR 使用AssemblyLoadContext来隔离不同上下文的程序集加载。Module 解析每个程序集包含一个或多个 Module通常只有一个。Module 是元数据的作用域。CLR 创建内部数据结构Module对象来持有元数据表。类型加载TypeLoader这是最复杂的阶段。类型加载器采用分级加载策略——不是一次性加载所有信息而是按需、分步加载。具体机制将在下一篇文章类型加载器中详述。关键数据结构有MethodTable类型的运行时身份证存储 vtable、接口映射、GC 布局信息EEClass类型的冷数据只在类型加载和反射时使用MethodDesc方法的运行时表示包含入口点Entry Point指针方法入口点的建立对于每个方法CLR 会创建一个 stub一小段跳转代码这个 stub 在方法首次被调用前指向 JIT 编译器的入口。当方法被首次调用时stub 跳转到 JITJIT 编译完成后将 stub 更新为指向编译后的机器码——这就是首次调用触发 JIT的机制。3.2 类型的运行时层次结构TypeHandle (抽象) ├── MethodTable (普通类型、泛型闭合类型) │ ├── Parent MethodTable (父类型) │ ├── Interface Map (实现的接口) │ ├── VTable Slots (虚方法表) │ └── GC Layout Info └── TypeDesc (指针、byref、泛型参数变量) ├── ParamTypeDesc (T[], T, T*) ├── FunctionTypeDesc (delegate*) └── TypeVarTypeDesc (泛型方法中的 T)这个层次结构决定了所有类型相关的运行时操作——对象分配newobj需要知道对象大小、方法分派callvirt需要查 vtable、GC 扫描需要知道哪些字段是引用——都是通过 MethodTable 完成的。四、第三阶段JIT 编译——IL 到机器码4.1 JIT 的触发与接口JIT 编译的最典型触发场景是方法首次被调用。具体流程调用方执行call或callvirt指令目标方法的入口点Entry Point指向一个Precode StubPrecode Stub 调用 JIT 编译器的compileMethod()入口JIT 将 IL 编译为机器码写入可执行内存Precode Stub 被改写backpatch为指向新生成的机器码后续调用直接跳转到机器码不再经过 JITJIT 编译器与运行时之间通过两个接口交互ICorJitCompilerJIT 端运行时调用 JIT定义在src/coreclr/inc/corjit.hcompileMethod()核心入口接收 IL 字节码返回机器码ICorJitInfo运行时端JIT 回调运行时定义在src/coreclr/inc/corinfo.hgetMethodDefFromMethod()获取方法元数据getClassAttribs()获取类型属性getFieldOffset()获取字段在对象中的偏移量4.2 RyuJIT 的编译阶段概览现代 .NET 使用 RyuJIT 编译器。它的编译流水线分为前端、中端、后端三大阶段包含超过 20 个子阶段前端 (Frontend) ├── Importation : IL → GenTree IR ├── Inlining : 内联候选方法的 IR ├── Morph : 形态变换字段访问→指针算术 中端 (Middle-end) ├── SSA Construction : 构建静态单赋值形式 ├── Value Numbering : 值编号消除重复计算 ├── CSE : 公共子表达式消除 ├── Range Analysis : 范围分析推导数组索引范围 ├── Bounds Check Elim : 边界检查消除 ├── Loop Optimization : 循环优化克隆、展开、IV 优化 ├── Dead Store Elim : 死存储消除 后端 (Backend) ├── Rationalization : HIR → LIR线性化 ├── Lowering : 暴露控制流和寄存器需求 ├── Register Alloc : 线性扫描寄存器分配 └── Code Generation : 遍历 IR 生成机器码每个阶段的具体细节将在后续文章JIT 编译管线、JIT 优化全景中详细展开。这里先建立一个全局视图GenTree IR是贯穿整个 JIT 的核心数据结构。前端使用树形节点父-子链接后端使用线性节点prev-next 链接。内联Inlining是最有影响力的优化——将小方法的代码直接嵌入调用方消除调用开销并启用更多的跨方法优化。SSA静态单赋值是 JIT 分析的数据基础——每个变量只被赋值一次使得数据流分析变得精确。值编号Value Numbering将语义相同的表达式映射到同一个编号使得 CSE 能识别并消除冗余计算。4.3 源码位置JIT 编译器源码全部在dotnet/runtime/src/coreclr/jit/目录下文件内容compiler.cpp/compiler.hppCompiler 主类gentree.cpp/gentree.hGenTree IR 定义morph.cpp形态变换inline.cpp内联决策和实现ssa.cppSSA 构建valueNum.cpp值编号rangecheck.cpp范围分析和边界检查消除loopcloning.cpp/loopunroll.cpp循环优化rationalize.cppIR 理性化lower.cpp/lsra.cppLowering 和寄存器分配codegen*.cpp代码生成五、第四阶段AOT 编译——另一种执行路径5.1 为什么需要 AOTJIT 编译的优势在于可以利用运行时的实际类型信息做特化优化、可以动态生成代码。但它有两个致命弱点冷启动慢应用启动时需要编译大量代码需要运行时可写可执行内存iOS 等平台不允许 JITAOTAhead-of-Time编译在应用部署之前就将 IL 预编译为机器码解决了这两个问题——但代价是失去了 JIT 的灵活性。5.2 三种 AOT 方案.NET 生态中有三种主要的 AOT 方案ReadyToRunR2R发行版中包含预编译的机器码 IL作为回退运行时会利用 R2R 代码加速启动但仍可用 JIT 处理未预编译的方法需要 JIT 运行时仍然存在源码位置dotnet/runtime/src/coreclr/tools/crossgen2/NativeAOT将整个应用完全预编译为原生代码包含一个精简的运行时GC、异常处理、线程管理但没有 JIT不支持System.Reflection.Emit、Assembly.Load动态加载需要提前注册泛型实例化源码位置dotnet/runtime/src/coreclr/nativeaot/IL2CPPUnity 专用工作流C# → IL DLL → IL2CPP 转换器 → C 源码 → 平台 C 编译器 → Native泛型处理编译时分析代码引用为值类型泛型生成特化代码引用类型泛型使用共享代码对数据结构的直接影响缺失的泛型实例化会在运行时抛MissingMethodExceptionIL2CPP 本身的源码属于 Unity 的专有技术不完全开源5.3 AOT 对数据结构的限制AOT 编译下以下与数据结构相关的特性受到限制特性JITAOT (NativeAOT/IL2CPP)dynamic关键字✅ 运行时动态绑定❌ 需要 JIT 编译器Reflection.Emit✅❌ 完全不可用MakeGenericMethod(typeof(X))✅⚠️ 仅限已注册的类型Assembly.Load✅❌ 不支持动态程序集ListMyStruct✅ 运行时 JIT 特化⚠️ 需在编译期确定六、机器码执行时的运行时服务编译得到的机器码不是孤立运行的。它在每一步执行中都得到运行时的服务6.1 GC 的协作JIT 编译器生成的机器码中嵌入了GC 信息GC Info哪些寄存器/栈位置在代码的哪个点持有活动 GC 引用GC 安全点Safe Point可以安全暂停线程进行 GC 的代码位置写屏障Write Barrier当引用字段被赋值时JIT 在赋值指令后插入写屏障代码——标记跨代引用的卡表Card Table写屏障是 GC 高性能的关键。如果没有它每次 Minor GC仅回收 Gen0都需要扫描所有 Gen2 对象的引用——那将是灾难性的性能开销。有了写屏障GC 只需扫描卡表中标记的被修改过的内存页。6.2 异常处理C# 中的try-catch-finally在 IL 层面是通过受保护区域Protected Region表达的在机器码层面则映射到平台的展开表Unwind Table。当异常发生时运行时根据展开表找到对应的方法帧执行正确的 catch 或 finally 处理。6.3 空引用检查C# 中访问空引用成员会抛出NullReferenceException。这不是编译器插入的显式检查——而是利用硬件的页面保护机制地址 0 附近的页面被标记为不可访问任何对空指针的解引用都会触发硬件异常Access Violation运行时捕获这个异常并转换为NullReferenceException。这个设计使得空引用检查几乎零性能开销。七、Unity 中的特殊编译链路Unity 开发者面对的是一个混合的编译世界7.1 编辑器模式[编辑器模式] C# 源码 → Roslyn → .NET DLL → Mono Runtime (JIT) ├── 编辑器中的脚本编译极快增量编译 ├── Play Mode 进入时无预编译等待 └── GC 使用 Boehm保守式非分代编辑器模式的体验很流畅脚本修改后几乎立即生效。但要注意编辑器中的 JIT 行为和真机的 AOT 行为可能有很大差异——某些在编辑器正常运行的功能如dynamic、Reflection.Emit在 IL2CPP 真机 build 中会直接崩溃。7.2 IL2CPP 构建模式[IL2CPP 构建模式] C# 源码 → Roslyn → .NET DLL → IL2CPP 转换器 → C 源码 → 平台 C 编译器 (Xcode/MSVC/Clang) → Native Binary ├── 构建时间长C 编译 链接 ├── 不支持 JIT 依赖特性dynamic、Reflection.Emit └── 泛型需要提前确定所有实例化Unity 6 的 C# 版本支持官方支持 C# 9.0编译器使用 RoslynAPI 兼容级别.NET Standard 2.1这意味着 C# 10/11/12 的新特性如全局 using、主构造函数、集合表达式、list patterns在 Unity 中默认不可用。但有部分特性可以通过手动配置csc.rsp文件来尝试启用——前提是它们不依赖新的运行时特性例如集合表达式需要 C# 12 的CollectionBuilderAttribute。八、关键源码索引下表汇总了本篇涉及的所有关键源码位置组件仓库关键路径Roslyn C# 编译器dotnet/roslynsrc/Compilers/CSharp/Portable/CoreCLR 运行时dotnet/runtimesrc/coreclr/vm/RyuJIT 编译器dotnet/runtimesrc/coreclr/jit/CoreCLR GCdotnet/runtimesrc/coreclr/gc/gc.cppNativeAOTdotnet/runtimesrc/coreclr/nativeaot/Mono 运行时dotnet/runtimesrc/mono/BOTR 架构文档dotnet/runtimedocs/design/coreclr/botr/Roslyn 架构文档dotnet/roslyndocs/compilers/CSharp/IL2CPP (Unity)Unity 内部非开源九、总结从var list new Listint()这行代码到 CPU 真正执行ListT.Add的机器码中间经历了Roslyn将它解析为语法树 → 绑定为语义模型 → 发射为 IL 字节码CLR 加载器将它注册为运行时类型创建 MethodTable 和 MethodDescJIT 编译器首次调用时将 IL 编译为最优机器码经过 20 个优化阶段或者AOT 编译器在构建期就将它预编译为机器码以牺牲灵活性换取启动速度运行时在执行时持续提供 GC 协作、异常处理和安全检查理解这个全链路就像打通了任督二脉。后续每一篇关于ListT扩容、Dictionary哈希碰撞、SpanT零分配的文章都会反复回到这个链路中的某个环节来解释为什么会这样设计和为什么性能是这样。下一篇MethodTable一切类型的运行时身份证