OCaml 运行时：值表示、GC、尾调用与性能分析

OCaml 代码看起来接近数学表达式，但运行时并不是抽象的黑箱。variant 要选择内存表示，闭包要保存环境，偏应用可能分配，浮点多态可能装箱，不可变数据更新也会创建新堆块。

性能优化的正确顺序不是放弃函数式风格，而是建立成本模型：

1. 哪些值不需要堆分配；
2. 哪些表达式会创建短命对象；
3. 数据何时进入 major heap；
4. 哪些递归能复用栈帧；
5. 并行后分配、同步与缓存行为如何变化；
6. 剖析数据是否证明这里值得优化。

ocamlc 与 ocamlopt

OCaml 提供两条经典编译路径：

• ocamlc 生成字节码，由 OCaml bytecode runtime 执行；
• ocamlopt 生成目标平台原生代码。

字节码通常编译快、便于快速迭代和某些工具场景；原生代码通常拥有更高执行性能和更深入优化。生产服务与 CPU 密集程序一般使用 native executable。

这不是 JVM 的“先生成统一字节码，再由 JIT 在运行时持续优化”的同一模型。OCaml 原生构建主要依靠 ahead-of-time 编译；运行时仍负责 GC、异常、Domain 和系统接口，但常规执行不依赖 HotSpot 式分层 JIT。

一个值通常占一个机器字

OCaml 运行时使用统一 value 表示。很多值可以直接放进一个机器字，另一些值用指针指向 heap block。

整数通常使用 tagged immediate representation：机器字的一部分位保存整数，最低位标记它不是堆指针。这使普通整数无需单独堆分配，但可表示范围比原生机器有符号整数少一位。

let answer = 42

answer 通常就是一个立即值。

布尔、字符、()、空列表以及无载荷常量构造器也可以使用立即数编码。运行时和 GC 能快速区分立即值与指向托管堆的指针。

int 不是 Int32/Int64

int 随平台机器字变化，并为 tag 保留一位。需要固定宽度时使用 Int32、Int64 或 Nativeint。

这些类型的运行时表示和操作成本与普通 immediate int 不完全相同。协议字段、数据库整数和位运算边界必须根据宽度语义选择，不能只因 int 写起来短。

heap block：头部加字段

tuple、record、带载荷 variant、数组、字符串和闭包通常表示为 heap block。block 具有 header，记录大小、tag 与 GC 所需信息，随后是字段。

type user = {
  id : int;
  name : string;
}

user record 通常是一个 block，字段中保存 immediate int 与指向 string block 的值。

variant 的 tag 可区分构造器：

type state =
  | Idle
  | Ready of string
  | Failed of int * string

Idle 没有载荷，可以是立即值；Ready 与 Failed 需要 block 保存字段。源码中“只是一个构造器”不代表运行时没有分配。

float 的特殊成本

OCaml 的通用值槽以机器字表示。浮点数需要完整 IEEE 754 double 位，因此普通 float 放入多态容器或普通 record 时通常需要 boxed representation。

let values =
  [1.0; 2.0; 3.0]

普通 list 节点与浮点 box 都可能产生分配。

float array 使用专门表示，元素可以连续存放而不逐个装箱：

let values =
  [| 1.0; 2.0; 3.0 |]

数值密集代码应关注：

• 使用通用多态容器是否导致 boxing；
• array/bigarray 是否更符合连续访问；
• record 中大量 float 是否需要特殊表示或布局优化；
• FFI 是否在边界重复复制与装箱。

不要只根据源码行数判断成本。List.map 浮点列表可能比一个命令式 array loop 分配得多。

闭包保存代码与环境

不捕获外部值的函数可以只引用代码；捕获变量的函数需要保存环境：

let greater_than threshold =
  fun value ->
    value > threshold

greater_than 10 产生的闭包至少要保存 threshold。

偏应用也可能创建闭包：

let add left right =
  left + right

let add_ten =
  add 10

完整应用 add 10 20 不一定实际分配中间闭包，编译器可以识别调用 arity；真正把偏应用结果作为值保存时，环境通常必须存在。

性能敏感循环中应警惕：

• 每次迭代创建捕获 lambda；
• 只为传一个常量而重复偏应用；
• 多层 map/filter 产生多个中间结构；
• 闭包捕获大型对象，延长其可达生命周期。

但不要手工展开所有高阶函数。先用 profiler 证明闭包分配或中间集合是热点，再局部融合循环。

分代 GC 的基本模型

OCaml 使用分代垃圾收集。大多数新分配先进入 minor heap；存活足够久的对象被提升到 major heap。

这利用 generational hypothesis：多数对象寿命很短。

函数式代码经常创建短命 tuple、list node、variant 和闭包。只要它们很快失去引用，minor allocation 与 collection 可以非常高效。因此“有分配”不等于“性能一定差”。

真正需要关注的是：

• 分配速率是否过高；
• 对象是否意外长期存活并晋升；
• major heap 是否持续增长；
• 大对象是否绕过或很快离开 minor heap；
• 写屏障和 remembered set 是否成为成本；
• GC pause 和吞吐是否符合目标。

minor heap 与 major heap

minor heap 适合顺序快速分配。触发 minor collection 时，存活对象被复制或提升，死亡对象整体回收。

major heap 保存长期对象，由增量/并行化的 major collector 管理。OCaml 5 的多 Domain 运行时需要协调每个 Domain 的本地分配与共享 major heap；具体暂停、并行标记和调度行为会随版本演进。

因此不要背诵某个版本的精确暂停模型作为永恒事实。对生产版本，应结合对应 manual、runtime parameters 和实际指标判断。

跨代指针需要写屏障

若 major heap 中的可变对象指向新创建的 minor 对象，GC 必须记录这条引用，否则 minor collection 可能漏掉仍被老对象持有的新值。

这就是写屏障和 remembered set 的作用。频繁修改长期存活容器、让它们指向大量短命对象，可能产生额外 GC 成本。

不可变数据减少此类写入，但持续保留历史版本也可能让大量结构长期可达。不可变不是免费午餐，关键仍是对象图生命周期。

多 Domain 下的堆

每个 Domain 拥有自己的 minor allocation 区域，major heap 在 Domain 间共享。局部短命分配通常保持良好局部性；被多个 Domain 长期共享或修改的数据则需要更多协调。

并行扩展受多种因素限制：

• 任务本身的串行部分；
• Domain 间同步；
• major heap 与 GC 工作；
• cache line 争用和 false sharing；
• 内存带宽；
• 工作窃取与任务粒度；
• C stub 是否阻塞或持有运行时状态。

CPU 利用率达到 800% 不代表吞吐线性提升。应测量 wall time、吞吐、尾延迟、分配率与 GC 时间。

tail call：复用调用栈

尾位置调用是函数返回前的最后一步：

let rec sum accumulator = function
  | [] ->
      accumulator
  | value :: rest ->
      sum (accumulator + value) rest

递归调用结果被直接返回，不需要保留当前栈帧，因此编译器可以执行尾调用优化。

非尾递归：

let rec sum = function
  | [] -> 0
  | value :: rest ->
      value + sum rest

递归返回后还要执行加法，当前帧必须保留。长列表可能导致栈溢出。

可以用属性要求编译器检查某个调用确实处于尾位置：

let rec loop state =
  (loop [@tailcall]) (next state)

如果调用不是尾调用，编译器会给出警告。

tail recursion modulo cons

构造 list/tree 时，递归调用常被构造器包住：

let rec map transform = function
  | [] -> []
  | value :: rest ->
      transform value :: map transform rest

经典形式不是严格尾递归。OCaml 支持 tail recursion modulo cons 转换，在合适位置通过属性请求优化，使构造器上下文中的递归避免线性栈增长。

这种优化有适用条件，不应假设任意递归数据构造都会自动转换。标准库版本也会持续改进哪些函数已尾递归化。

persistent data structure 的共享

不可变更新不一定复制整个结构。

let original =
  [2; 3; 4]

let extended =
  1 :: original

extended 只新建一个 cons cell，尾部与 original 共享。

Map/Set 等树结构更新通常只复制从根到修改点的路径，其余子树共享。成本往往是对数级新节点，而不是完整拷贝。

但共享也会延长生命周期：只要旧版本仍可达，被共享的所有节点就不能回收。保留无限历史快照、闭包捕获旧根或缓存键值不淘汰，都可能造成 major heap 增长。

异常与正常分支

抛出异常需要构造/传播控制路径，捕获还可能涉及 backtrace。异常适合罕见失败，不适合高频正常分支。

标准库常同时提供：

• find：找不到抛异常；
• find_opt：返回 option。

如果未找到很常见，find_opt 通常更符合语义，也避免异常路径。若不变量保证一定找到，异常版本可以让违反假设快速暴露。

性能不是唯一判断标准，API 契约应先正确。

多态与专门化

Hindley–Milner 多态带来统一抽象，但通用表示可能导致装箱或间接调用。native compiler 与 Flambda 优化可以通过内联、常量传播、闭包简化和某些专门化消除成本。

是否生效取决于：

• 编译器版本与配置；
• 优化级别；
• 函数是否跨模块；
• .mli 是否隐藏了实现；
• 调用点是否可见；
• 代码体积预算与内联启发式。

不要把“高阶函数一定慢”或“编译器一定会优化掉”当成结论。两者都需要查看生成代码或 benchmark。

Flambda 是优化器，不是新语义

Flambda 系列优化针对函数、闭包、内联与跨模块信息做更强分析。它不会改变 OCaml 语言语义，也不会自动把所有抽象变成零成本。

接口抽象与优化可能存在张力：隐藏表示有利于模块边界，却可能限制调用方看到实现。编译器可以利用额外元数据缓解，但仍需在 API 稳定性和极端热点之间做局部取舍。

默认应保留正确抽象；只有 profiler 证明边界成本显著时，才考虑重构或暴露专用 fast path。

Marshal 与运行时表示不是稳定协议

Marshal 可以序列化许多 OCaml 值，但它不是适合不可信输入或长期跨版本存储的通用协议。

需要注意：

• 闭包和自定义块具有特殊限制；
• 类型信息不会自动随字节流提供安全验证；
• 读取不可信 marshal 数据可能具有严重安全风险；
• 编译器/运行时版本与类型变化会影响兼容；
• 长期数据应使用明确 schema 的格式。

生产网络协议、数据库字段和持久队列应优先采用可验证、版本化的序列化方案。

性能分析工具

可以从运行时统计开始：

let stats =
  Gc.quick_stat ()

let allocated =
  stats.Gc.minor_words
  +. stats.Gc.major_words

但单个快照不能解释热点。完整分析通常结合：

• wall-clock benchmark；
• allocation 与 promotion 指标；
• GC time 与 heap size；
• statistical memory profiling；
• Linux perf 或 macOS 原生 profiler；
• flame graph；
• memtrace 等生态工具；
• 不同输入规模与并行度；
• production trace。

微基准应防止死代码消除、预热缓存偏差和不真实输入。与 Kotlin/JVM 不同，OCaml 没有同样的 JIT warm-up 曲线，但 CPU frequency、page cache、allocator 和 GC 状态仍会污染结果。

优化的优先顺序

1. 先选择正确算法和数据结构；
2. 用真实负载找到 CPU、分配或 I/O 热点；
3. 消除意外保留的大对象与无界缓存；
4. 减少热点中的中间 list/tuple/closure；
5. 数值路径考虑 array、Bigarray 与专用表示；
6. 确认递归是否尾递归；
7. 调整并行粒度，避免共享写热点；
8. 最后才调 GC 参数、inline 属性和底层表示；
9. 每次优化都保留前后 benchmark；
10. 不牺牲整个系统可读性去优化冷路径。

与 JVM/Kotlin 的成本差异

Kotlin/JVM 的优势是强大的运行时 profiling 与热点优化；OCaml native 的优势是启动和执行模型更直接、尾调用得到语言生态支持。两者都需要理解装箱、分配与 GC，语法简洁不会自动带来低成本。

结论：函数式抽象有成本，也有优化空间

OCaml 的运行时模型可以概括为：

• immediate value 避免许多基础值分配；
• heap block 统一表示复合数据；
• float 与多态容器可能产生装箱；
• closure 保存代码和环境；
• generational GC 高效处理大量短命分配；
• persistent structure 通过共享降低更新成本；
• tail call 避免递归栈增长；
• native compiler 与 Flambda 尝试消除抽象开销；
• 多 Domain 带来并行，也暴露同步与共享堆成本。

好的 OCaml 性能工程既不恐惧分配，也不迷信编译器。先写出正确、清楚的模型，再用测量决定哪些抽象需要被局部压平。

下一章

下一章进入完整工程工具链：opam switch、Dune workspace/library/executable、依赖锁定、测试、格式化、odoc、PPX 和 CI，建立从单文件示例到可维护项目的路径。

延伸阅读

• OCaml 5.5 Manual：Runtime System
• OCaml 5.5 Stdlib：Gc
• OCaml Manual：Tail Modulo Constructor
• Real World OCaml：Memory Representation of Values
• Real World OCaml：Understanding the Garbage Collector