对话 Koichi Sasada:Ruby 线程和垃圾收集器的前景

  • Werner Schuster
  • 杨晨

2009 年 8 月 9 日

话题:Ruby语言 & 开发架构

根据计划,Ruby 1.9.2 将在年末发布。InfoQ 以1.9.2 Preview 1 的发布为契机,采访了 Ruby 1.9.x VM 的维护者Koichi Sasada先生,讨论了 VM 的前景、线程以及垃圾收集器的问题。

InfoQ:在 RubyConf'08 上您提到了在 1.9.x 上将会打开一些以前默认关闭的优化,但是您可能要到 1.9.2 才会打开这些优化。这个工作的进展如何?

Koichi Sasada:事实上,1.9.x 不会打开这些优化,我们需要做更多的实验来检查这些优化的效果。但是,我们没有时间来做这件事。而另外一些非常重要的优化将会包括在内。如果我能够有时间来做这件事的话,我倒是希望能够实现一些其他的想法,例如 Proc#call 优化。

InfoQ:Ruby 1.9.2 Preview 1 有一个长生命周期垃圾收集器的补丁。据我理解,一个只收集普通对象的垃圾收集器现在应该比以前更快了,因为它忽略了在长生命周期对象空间中的对象(直到一个完整的垃圾收集过程,包括处理长生命周期对象),是这样吗?

Koichi Sasada:是的,Nari 先生负责这方面的工作。有一些节点对象属于同一个层级。有些节点被当做内联缓存用来改善 VM 性能,这使得垃圾收集器要进行修改,忽略掉这部分内联缓存对象。

但是,我重写了内联缓存相关的代码,以避免节点对象。也就是说内联缓存将不会在使用节点对象。相应地,这个垃圾收集器的优化稍稍地改善了性能。

InfoQ:看起来这个补丁将会是迈向新一代垃圾收集器的第一步,尤其是关于处理写屏障和可记忆化集合的代码介绍。新一代垃圾收集器能否和 1.9.2 有缘呢?

Koichi Sasada:不,它仅仅是处理“不可见”对象。也就是说通过 C 扩展库不能够访问到的对象。如果代码的某一部分访问了这个对象,而且忘记使用写屏障,那么可能会导致一个非常严重的 BUG,例如段错误。CRuby(Matz)将不会允许这样的操作。另外一个日本研究人员(学生)在研究为需要写屏障的垃圾收集器(GC)实现自动插入写屏障(write-barrier,简写为 WB)。如果可行的话,下一代垃圾收集器(或者增量垃圾收集器)不再会是一个梦 :)

InfoQ:在 Ruby 1.9.x VM 中使用这个新一代的 GC 有什么困难呢?我认为移动对象也许是一个问题,这可能给原生扩展带来问题吗?

Koichi Sasada:问题是,就像我写的那样,GC 技术需要完善。如果某个人忘记添加了写屏障,那么会导致非常严重的问题。在这种背景下,另外一个日本研究人员提出了“多数标记压缩 GC”。这个技术以一种非常保守的方式运行,所以它不需要完整性(当然,GC 实现必须完整。我的意思是现有的扩展库接口不需要更改)。

InfoQ:Unladen Swallow 项目着重于将 GIL 从 Python 中移除。你们对于 1.9.2 或者未来更高版本中 GIL(或者 Ruby 中的 GVL)的态度是如何的呢?

Koichi Sasada:在 1.9.2 或者近期的一些版本中,我不可能发布 GVL(巨型 VM 锁,在 YARV 术语中是 GIL)。更遥远的将来我就不确定了。我也不确定我们是否会对 GVL 释放线程可用而感到高兴。因为,它使得代码更加难写。

InfoQ:你看过MacRuby 关于 GIL 问题的解决方案吗?

Koichi Sasada:干得很棒,我希望看到这个结果是可行的。如果每个 MacRuby 用户说他们非常“高兴”,那么我们就必须改变我们的态度了 :)

InfoQ:GVL 能够解决原生扩展的问题吗?

Koichi Sasada:GVL 不能解决任何问题 :)

其实,我的博士论文就是在多核环境下使用 GVL 改善性能。在我的并行 VM 上,会调用一个线程不安全的方法(使用 C 编写)。首先,VM 请求 GVL,然 后处理这个方法,接着释放 GVL。我的论文中,提出了一些关于这方面的优化和异常安全技术(很不幸的是,这是使用日语编写的)。

在我的并行 VM 上,VM 是线程自由的,也就是说并行执行是可行的。但是,仍然有很多线程不安全的方法存在。例如 String、Array 以 及更多内建的类的方法。将其转换为线程安全是一件简单(其实很困难,编写充满 bug 的代码倒是很简单)的工作(但是需要更多的努力)。所以我可以说,从实 现的角度来看,“它当然是可行的”。

但是,就正如我说的那样,从语言的角度来看,我不确定这个特性是否会使得我们感到愉快。

现在,我们在进行 MVM(多虚拟机)项目,这是一个由 Sun 赞助的项目。这个项目旨在使得在一个进程中调用多个 VM 成为可能,所有的 VM 都 可以并行地运行。我想这是比线程要更好的实现并行的方法,当然,如果 MVM 的操作的代价足够低。我们研究的目标之一就是努力降低这个代价。从 MVM 的角度 来看,我们不需要关注线程安全,但是需要考虑 VM 通讯。

这只是一个研究性项目,但是我希望早日能够应用到工业界。

在另外的项目中,我们打算使用并行性来解决问题。这个想法还在考虑之中,但是我希望我能够在下一次 RubyConf 的时候能够展示给大家看。

查看英文原文:Future of the Threading and Garbage Collection in Ruby - Interview with Koichi Sasada

Ruby语言 & 开发架构