Jane Street 是一家特别重视技术的贸易公司,同时也是目前世界上最大的 Caml 和 OCaml 用户。近日,该公司技术部门负责人 Yaron Minsky 撰文介绍了正在进行中的构建低延迟 OCaml GC 的工作。
在垃圾回收中,有一个众所周知的问题,就是它会导致不可预知的应用程序中断。虽然 OCaml GC 在延迟方面已经相当出色(一方面,“主堆(major heap)”回收增量进行,即可以“分片(slice)”完成;另一方面,“次堆(minor heap)”回收的速度也非常快),但它仍然存在一些问题:
- 没有性能分析:现有的运行时无法知道不同部分回收工作所耗费的时间,难以优化。
- 错误提升:在次堆回收时,如果对象恰巧出现短暂的不可达,那么它会被错误地提升到主堆中。
- 触发:如果服务器需要在突发流量的情况下仍然保持低延迟,那么我们希望垃圾回收可以延后,在应用程序空闲时执行。但现有的运行时根据次堆分配触发垃圾回收,无法满足此类场景。
- 增量回收不完善:主堆采用增量回收机制,但数组会一次性回收,所以当数组较大时会出现问题。
- 即时计算:现有的运行时根据上次次堆回收时提升到主堆的对象的多少来确定主堆片的大小。如果提升的对象很多,那么会立即进行主堆回收。但这时,正在进行的任务可能尚未完成。而且,对于快速响应系统,我们同样希望垃圾回收可以延后执行。
为了解决上述问题,他们在 OCaml GC 作者 Damien Doligez 的帮助下做了如下工作:
- 改进性能分析:为垃圾回收器增加了一组探针,详细记录垃圾回收过程的每个阶段。
- “老化(Aging)”:为了减少错误提升,允许对象在次堆中停留多个次堆回收周期。
- 完善增量回收:垃圾回收的多个阶段都改为可中断的,包括数组扫描。
- 将主堆片回收与次堆回收分离:在现有的运行时中,主堆片回收与次堆回收总是一起完成。但在低延迟分支中,二者可以在任意时间单独执行。同时,该分支允许在应用程序层面调度垃圾回收。
- 使工作计算更平滑:该低延迟分支由跟踪下次主堆片回收的工作量改为跟踪接下来 N 次主堆片回收的工作量,并将数值保存在一个环形缓冲区里。
- 空闲列表分段:查找空闲块的开销占次堆回收开销的一大部分。在许多 OCaml 应用程序中,块都非常小。为了利用这一点,他们正在该低延迟分支中实现一组根据尺寸划分的空闲列表。
虽然许多工作还在进行之中,但已经取得的成果让他们觉得这项工作非常有前途。通过使用一个包含了上述大多数更改的编译器版本及应用程序驱动的垃圾回收作业,他们目前已经在一个真实的生产应用中将“尾延迟(tail latency)”降低到了原来的 1/3。不过,也有部分成果不尽人意。比如,老化机制节省了对象提升开销,但次堆回收本身的开销增加了,两者基本相互抵消了。
感谢徐川对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流。
评论