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