通用Ruby多虚拟机API研究开始啦

过去Ruby在多核机器下运行是一个大问题 。直到Ruby1.8，Ruby的解释器一直在使用用户空间线程（userspace threading ），这意味着线程是由Ruby解释器调度运行的。Ruby 1.9通过使用内核线程（kernel threads ）改变了这一切——除了它使用一个像Python那样的全局解释器锁（Global Interpreter Lock，即GIL）。GIL意味着一次只能运行一个Ruby线程，而本地代码就可以多线程方式运行。

运行在JVM上的JRuby早已开始支持本地线程了。对于多核的一个解决方案是运行多个Ruby进程，这些进程可由操作系统在多核之间调度。而JRuby线程可以使用多核，像Rails之类的应用——并不是线程安全的，他们必须使用JRuby进程——对JRuby来说这也会成为一个合适的解决方案。

使用多个Ruby虚拟机会产生很多部署问题，像如何加载新的Ruby进程、如何与其他进程通信等等。最明显的问题就是加载一个新的Ruby进程。通过下面简单的方式来加载一个新的Ruby进程

system("ruby", file_to_run)  

然而如果上面的代码运行在JRuby下，那么很多时候会产生失败的结果，前提是系统中唯一的Ruby实现就是JRuby，而它则必须由“jruby”加载。性能问题也是值得关注的：使用“'jruby” 命令加载一个或多个JRuby会导致多个JVMs的加载。既然多个JRuby实例可以共享相同的JVM，那么这就是不必要的了。但是，需要特定于JRuby的代码来完成新实例的实例化工作，这会根据主机架构的不同而发生变化，如BSF或者Java6中的实现。

Rubinius是一个Ruby实现，它现在也在使用用户空间线程， 最近它还增加了多虚拟机支持 。通过下面的代码

vm = Rubinius::VM.spawn "blah", "-e", "puts 'hello\n'"  

可以加载一个新的虚拟机。这个方案确实使用了多核，因为每个虚拟机都运行在其本地线程上。这表示所有的虚拟机都驻留在同一个操作系统的地址空间中并且并行运行。但是虚拟机不能共享任何引用，或者说——任何东西；唯一的通信手段是通过一个特定于Rubinius的消息传递API。

所有这些不同的解决方案归纳如下：跨越Ruby实现来编写运行于多核上的代码是不切实际的，因为每个Ruby实现都需要不同的处理。举例来说，如果一个程序想要使用Skynet（MapReduce的Ruby版本 ），还想使用多虚拟机来并行运行任务，那么其必须进行适配以适合每种Ruby实现。

该问题有可能被一个新的研究项目所解决，该项目是由东京大学与Sun的JRuby小组联合发起的，目的在于寻求能工作于所有Ruby实现的解决方案。下面的内容来自新闻：

由东京大学信息科学与技术研究所的Ikuo Takeuchi教授领导的小组将联合Sun的Tim Bray（Web技术主管）与JRuby小组成员一起去实现可应用于Ruby与JRuby的多虚拟机（MVM）环境。该MVM环境目的在于使Ruby程序更加高效地运行。按计划，研究成果将通过Ruby社区开源，这会激发更多的创新。

以前，在Ruby上同时运行一个以上应用时需要多个解释器，这造成内存的浪费。MVM环境会在一个解释器上产生多个虚拟机实例，这会让应用的运行效率得到提高。该协作研究的目的在于明确技术问题如使用MVM的通用接口定义，虚拟机实例的并行运行以及内存共享，接下来实现可应用于Ruby与JRuby的技术。因为Ruby已经在商业和其他环境中得到了广泛的应用，所以对MVM的研究将进一步增进Ruby的性能和用途。

简而言之，期望的结果就是产生出可以加载和使用多个Ruby虚拟机的通用API。通过该通用API，每个Ruby实现将有一个后盾以确保提供最有效率的实现。对于Rubinius和JRuby，虚拟机可以共享相同的地址空间；对于老版本的Ruby，可以加载多个进程。

该API的另一个重要方面是定义虚拟机之间如何通信。可以利用Rubinius的消息传递方案，因为像Erlang这样的系统利用它来避免很多共享内存的问题。在JSR-121 Application Isolation API还使用了一个相似的解决方案。

查看英文原文： Common Ruby MVM API research kicked off 译者简介：张龙，同济大学软件工程硕士，现就职于理光软件研究所。主要从事文档工作流和办公自动化解决方案的研发工作。热衷于Java轻量级框架的研究，对敏捷方法很感兴趣。曾有若干年的J2EE培训讲师经历。参与InfoQ中文站内容建设，请邮件至 china-editorial[at]infoq.com。