对话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