MagLev：Gemstone基于Smalltalk虚拟机构建Ruby运行时

OODB厂商Gemstone正致力于开发一个名为“MagLev”的Ruby虚拟机。InfoQ对MagLev的产品经理Bob Walker进行了访问来获得项目背后的细节，Avi Bryant也参与到了项目中来。首先，我们和Bob Walker进行了交流。

InfoQ: 在虚拟机级别，Gemstone/S和MagLev有什么联系？

毫无疑问，MagLev和Gemstone/S共享了大量的代码和功能，但是它们是独立的产品，包括在虚拟机级别。MagLev虚拟机使用的大量字节码和算法都是Ruby独有的。然而，它当然还是保留了可以运行Smalltalk代码的能力。

InfoQ: 有多少人参与这个项目？目前有时间方面的计划吗？

目前有8个至少是兼职的人在开发MagLev。我现在的确还说不出时间点来，但是在RailsConf上我会说一些在时间方面的计划。

InfoQ: MagLev由什么语言编写？是一种“倒退”吗？

我们的目标和Rubinius项目类似：支持由Ruby实现的标准库中的全部方法，除了一些性能敏感的部分。虚拟机是由C编写的。

InfoQ: 是为虚拟机生成字节码还是为其他的什么方式？

是的，我们为虚拟机生成字节码，可以为多种架构产生不同的原生代码。

InfoQ: 你用什么来解析Ruby？（是纯Ruby的ruby_parser还是别的什么自制的解析器？）

我们有能力借鉴众多解析器来自行开发用于编译的和一个解析器的内部实现。我们尚未决定在最终发布时采用哪个解析器。

InfoQ: 除了Ruby标准，你们有从Rubinius项目中借鉴什么吗？

我正在通过Rubinius的bm脚本和测试来手机不同Ruby实现的性能指标。我还借鉴了MSpec的实现，包括脚本和测试，来帮助我们确保MagLev在API级别可以和Ruby标准兼容。这也就是说，我也在查看其他的Ruby实现。
我们真心希望最终可以和Rubinius尽可能多的共享标准库代码。

InfoQ: 你对于1.0版本在性能方面的预期是什么？

相对于单纯的性能来说我们更关注与可伸缩性。当然我们相信和其他的实现相比MagLev在性能方面还是有竞争力的，我们还相信我们的可伸缩持久化架构将成为最大的卖点。

InfoQ: 说一说MagLev的线程？是原生1:1线程、m:n模型还是普通用户空间线程？

每一个独立的虚拟机是一个普通用户空间线程。然而，多虚拟机之间可以写协同并发访问同一对象，所以实际上最终的效果和m:n模型类似。

InfoQ: 考虑到你将会参加RailsConf，可以说说Rails兼容性的目标吗？或者其他的什么（比如merb）？

这真是个有趣的问题，我们也投入了大量的精力在上面。我们当然希望MagLev可以兼容Rails。但 是这个不容易做到，因为我们已经有所了解在实现过程中有太多太多潜在的（和实际存在的）陷阱。在支持Rails以前我们必须先完全支持Ruby。我们也关 注其他的替代品，我们希望可以支持所有用Ruby编写的东西。至于先做什么后做什么，一个很主要的参考就是我们从Ruby社区收集到的热点和反馈。

InfoQ: 你计划让ActiveRecord在OODB下工作，还是用户定制或者使用MagLev特定的API？

让ActiveRecord在MagLev DB下工作是一个十分令人期待的目标，尽管部分ActiveRecord的API假定对象状态存储在基于SQL的RDB中。这可能会导致耦合。在任何事件 中，任何在ActiveRecord之下的API可能对于不希望使用ActiveRecord的用户都是可用的。对于我来说，现在过多的谈论这个话题为时 尚早，我希望社区可以让我们知道哪种方法是最有益的。

InfoQ: 你计划MagLev是作为标准Ruby的一个简易替换，还是它将使用某种类似Smalltalk风格基于映像的部署方式？

对于MagLev来说绝对是作为简易替换的。但是对于那些更喜欢基于映像部署方法的人，MagLev同时也是支持的，但并不强迫使用。

InfoQ: Ruby代码进程可以被持久化成一个映像吗？

简言之，是的。例如，GLASS系列产品目前可以让你将出错的进程保存到仓库中，然后迟些时候将它们放入一个本地的虚拟机中进行调试。没理由Ruby不支持。

InfoQ: 你将会和GLASS系列产品采用相似的授权模型吗？

我们查看了许多不同的模型。我可以说（但不保证）在MagLev上我们会做类似的事情。

InfoQ: 目前有用于MagLev的工具吗？你是否在寻求Ruby IDE的支持以作为前端（例如用于调试GUI等等）？

当然我们有一个IRB的shell，和一个类似ruby的命令用于在MagLev上运行Ruby代码。我希望看到IDE插件，但是我也不敢猜想何时GUI工具将会实现。
需 要提到的是，MagLev团队计划要参与并支持Ruby社区，我们希望社区成员可以看到一些令人感兴趣的理由来贡献MagLev。我们在GemStone 的核心竞争力是动态语言、可伸缩虚拟机和原生语言对象持久化——其他人中有很多在工具和UI方面十分擅长，我们欢迎他们对MagLev做出贡献。

InfoQ: 在MagLev上的Ruby代码有机会能和Smalltalk代码或者对象进行交互吗？

MagLev虚拟机不但支持Ruby，而且完美的支持Smalltalk。我得说能够做到这样非常棒，但是在我们在这个方向上深入以前，我们要看看这是否是一个需求强烈的功能且对社区有用。

Gemstone在开源技术上已经深耕一段时间了——例如为在Gemstone/S上运行Seaside web框架提供了解决方案。这个叫做GLASS——GemStone、Linux、Apache、Seaside和Smalltalk。GLASS是免费的，带有一个数据库，容量为4 GB，同时也有其他的授权方式。

Seaside由Avi Bryant所创建，作为重用Smalltalk虚拟机用于Ruby这个想法的推广者之一（参见他在这个话题的文章《Turtles all the way down》）。在一个视频采访中（很快将由InfoQ发布），Avi Bryant将会给出更多关于他致力于Seaside和DabbleDB的信息，以及他在GemStone的工作和MagLev。对于这个项目Avi说道：

我已游说Smalltalk提供商多年来使他们的技术被Ruby社区所熟知，现在令人激动的是它终于实 现了。我们还有不到三个月就可以完成MagLev的开发，但我已经被结果深深的鼓舞，而且我们将会在RailsConf上展示一些很棒的演示实例。恐怕在 那之前我还不能说的太深入，来看我们的讲座吧，这样会了解到更多的。

在一篇最近的blog帖子中，Avi给出了一个关于像Gemstone之类的OODB的优势介绍， 在其中比较了他们的那些基于Rails构建的接解决方案，使用了memcachedb和其他相似的技术：

关于Gemstone，凑巧架构完全相同：有一个单独的存储引擎（名叫“stone”），一个在每个服 务器上的内存缓存（叫做“共享页面缓存”），还有一些Smalltalk虚拟机的工作进程（“gems”）。gems用来处理请求并执行代码，它们将对象 贮存在页面缓存中以加速，并放入stone中以持久化。区别在于，在Gemstone中，它们的自底向上被设计的尽可能的迅捷和无缝。

注意：这篇blog帖子更为深入，并且给出了一个解决方案和其他方法概览。

GemStone将会在5月份的RailsConf 2008上更为详细的介绍MagLev。

查看英文原文：MagLev: Gemstone builds Ruby runtime based on Smalltalk VM