# 全值传递语义语言的编译实现：Herd 的零共享内存模型解析 > 深入分析纯值传递语义语言的编译器实现策略，涵盖写时复制、引用计数与逃逸分析如何协同工作以消除数据竞争。 ## 元数据 - 路径: /posts/2026/01/26/pass-by-value-semantics-compiler/ - 发布时间: 2026-01-26T10:33:33+08:00 - 分类: [compilers](/categories/compilers/) - 站点: https://blog.hotdry.top ## 正文 在现代编程语言设计中，值语义与引用语义的抉择始终是核心议题。大多数主流语言选择混合模型：基本类型按值传递，而复合类型按引用传递。这种设计在带来便利的同时，也引入了共享可变状态的复杂性。Herd 作为一款实验性解释型语言，尝试了一条激进的路径——**everything is pass-by-value**，包括列表和字典等容器类型。这种设计背后的编译器实现策略值得深入探讨。 ## 局部推理与共享状态的矛盾 传统编程中，理解一段代码的行为往往需要追踪所有可能访问共享状态的代码路径。当一个列表被传递给多个函数时，调用者无法确定这些函数是否会修改原始数据。这种不确定性迫使程序员在调用前后手动复制数据，或者依赖文档约定来约束副作用。Google Research 的研究表明，**局部推理**是应对软件复杂性的关键原则：要理解程序如何工作，推理和规约应该局限于代码实际访问的变量，其他变量的值自动保持不变。 纯值语义通过消除变量间的状态共享来解决这一问题。每个变量都是独立的数据副本，函数调用永远无法修改调用者的数据。这种保证不是通过文档规范实现的，而是由语言的类型系统和运行时共同强制执行。Herd 语言正是这一理念的实践者：即使对于列表和字典这样的复合类型，传递给函数的也是值的完整副本，而非对原始数据的引用。 ## 写时复制与引用计数的协同机制 实现纯值语义最直接的方式是每次赋值时复制整个数据结构，但这会造成严重的性能问题，尤其对于大型容器。Herd 采用**写时复制（Copy-on-Write, CoW）**配合**引用计数**来解决这一矛盾。其核心规则简洁而精妙：当复制一个引用类型变量时，仅增加引用计数，不复制实际数据；只有当尝试修改已共享的数据时，才触发浅拷贝。 具体而言，当引用计数为 **1** 时（即当前变量是数据的唯一持有者），修改可以**原地进行**，因为不存在其他代码能够观察到这一变化。当引用计数大于 **1** 时，语言运行时会在修改前创建数据的浅拷贝，新副本的引用计数为 **1**，后续修改通常不再需要分配内存。这种策略在大多数场景下避免了不必要的数据复制，同时保持了值语义的不可变性保证。 值得注意的是，纯值语义带来了一个额外的收益：**引用循环不可能发生**。因为所有赋值操作都创建的是独立副本，而非引用，这从根本上消除了循环引用的问题。这意味着引用计数系统无需额外的循环检测逻辑，计数归零即可安全释放内存，等同于一个完整的垃圾回收器。 ## 固定大小值的栈上分配策略 Google Research 的论文进一步形式化了可变值语义的实现策略。核心思想是利用值语义的固有属性来解锁激进的编译器优化。**固定大小的值**（如整型、浮点型、结构体）可以直接在栈上分配，无需任何堆分配开销。栈分配不仅避免了内存碎片化，还能利用调用栈的生命周期管理实现自动释放。 更重要的是，栈分配使得传统的编译器优化技术得以直接应用，包括**常量传播、死代码消除**以及**循环不变式外提**等。由于值的生命周期完全由词法作用域决定，编译器可以在编译期精确确定变量的使用范围，从而进行更激进的优化而无需保守的别名分析。 对于**动态大小的容器**（如可变长数组、哈希表），论文建议采用写时复制策略来缓解复制成本。容器在传递时共享底层存储，只有当某个副本被修改时才进行真正的数据复制。这种混合策略在保持值语义保证的同时，将性能开销控制在可接受范围内。 ## 并发场景下的安全性与性能权衡 Herd 内置的 `Parallel` 模块展示了值语义在并发编程中的独特优势。由于任何 mutation 操作只影响当前线程，**数据竞争从根本上不可能发生**。在并行映射操作中，每个工作线程获得数据的独立副本，修改互不干扰。线程间唯一的通信方式是通过返回值，这天然遵循了消息传递的并发模型。 然而，这种安全性是有代价的。原子引用计数的递增和递减操作会在并发场景下引入同步开销。Herd 的性能文档坦承，原子引用计数是当前最大的性能瓶颈之一，尤其是在热循环中的数组修改操作。优化的方向是将原子操作从热路径中提升出来——由于值语义保证了独占访问，一旦代码获得唯一引用，就可以在非原子上下文中安全地进行多次修改。 另一个值得关注的权衡是**动态类型系统**。Herd 作者选择动态类型是为了简化实现并探索这一概念在动态语言中的可行性。动态类型使得某些编译器优化难以实施，如类型特化（type specialization）和虚函数内联。单一遍 JIT 编译器的设计也限制了优化空间——更高级的 tracing JIT 可能提升性能，但代价是显著增加的复杂性。 ## 工程实践中的启示 Herd 作为一款实验性语言，其价值不在于生产应用，而在于验证纯值语义的可行性边界。从工程角度看，这种设计在以下场景具有吸引力：**脚本和原型开发**中需要快速推理代码行为；**教学和研究**中探索语言设计空间；**安全关键系统**中需要消除数据竞争的隐患。 对于主流语言的开发者，Herd 的设计提供了可借鉴的思路。Swift 已经在生产语言中实现了类似的**可变值语义**（Mutable Value Semantics），通过 `isKnownUniquelyReferenced` 函数提供类似的唯一性检查。Rust 的借用检查器虽然路径不同，但也致力于消除数据竞争。这些实践表明，值语义不是学术游戏，而是具有实际工程价值的编程范式。 --- **资料来源**： - GitHub: [jcparkyn/herd](https://github.com/jcparkyn/herd) - Google Research: "Mutable Value Semantics" (JOT 2022) ## 同分类近期文章 ### [C# 15 联合类型：穷尽性模式匹配与密封层次设计](/posts/2026/04/08/csharp-15-union-types-exhaustive-pattern-matching/) - 日期: 2026-04-08T21:26:12+08:00 - 分类: [compilers](/categories/compilers/) - 摘要: 深入分析 C# 15 联合类型的语法设计、穷尽性匹配保证及其与密封类层次结构的工程权衡。 ### [LLVM JSIR 设计解析：面向 JavaScript 的高层 IR 与 SSA 构造策略](/posts/2026/04/08/jsir-javascript-high-level-ir/) - 日期: 2026-04-08T16:51:07+08:00 - 分类: [compilers](/categories/compilers/) - 摘要: 深度解析 LLVM JSIR 的设计动因、SSA 构造策略以及在 JavaScript 编译器工具链中的集成路径，为前端工具链开发者提供可落地的工程参数。 ### [JSIR：面向 JavaScript 的高级 IR 与碎片化解决之道](/posts/2026/04/08/jsir-high-level-javascript-ir/) - 日期: 2026-04-08T15:51:15+08:00 - 分类: [compilers](/categories/compilers/) - 摘要: 解析 LLVM 社区推进的 JSIR 如何通过 MLIR 实现无源码丢失的往返转换，并终结 JavaScript 工具链碎片化困境。 ### [JSIR：面向 JavaScript 的高层中间表示设计实践](/posts/2026/04/08/jsir-high-level-ir-for-javascript/) - 日期: 2026-04-08T10:49:18+08:00 - 分类: [compilers](/categories/compilers/) - 摘要: 深入解析 Google 推出的 JSIR 如何利用 MLIR 框架实现 JavaScript 源码的高保真往返，并探讨其在反编译与去混淆场景的工程实践。 ### [沙箱JIT编译执行安全：内存隔离机制与性能权衡实战](/posts/2026/04/07/sandboxed-jit-compiler-execution-safety/) - 日期: 2026-04-07T12:25:13+08:00 - 分类: [compilers](/categories/compilers/) - 摘要: 深入解析受控沙箱中JIT代码的内存安全隔离机制，提供工程化落地的参数配置清单与性能优化建议。