BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Werner Schuster 关注 7 他的粉丝 ,译者 杨晨 关注 0 他的粉丝 发布于 2009年8月10日. 估计阅读时间: 6 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

根据计划,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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT