对话 Koichi Sasada：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