GE Energy 利用 InvokeDynamic 指令将 Magik 移向 JVM

今年 7 月，GE 能源管理业务（GE Energy Management）从 GE 能源集团分离出来。同月，其数字能源部门（Digital Energy）透露，他们正在将Magik（一种受Smalltalk 启发而设计的编程语言）从其专有的虚拟机MagikSF 移植向JVM。

Magik 是一种动态类型的面向对象语言，支持多重继承和多态。它最初出现于 1990 年，比 Java 还要早。Magik 已用于 GE 能源集团的 Smallworld 技术平台，而且该语言就是为实现面向企业设施（如配电）和电信的复杂应用而设计的。比如在电信领域，GE 能源管理业务有一款名为 Physical Network Inventory 的产品，支持电信公司规划和管理其铜线、光纤和电缆的电信网络。在企业设施方面，其产品 Electric Office 为配电公司提供了类似功能。

Magik 看起来非常像 Ruby。下面是一个简单的“hello world”例子程序：

 
Magik> _for i _over 1.upto(3)
               _loop
               write("Hello world ", i)
               _endloop

在 Ruby 中写法如下：

 
1.  upto(3) do |i|
 puts("Hello world #{i}")
end

这两段代码的输出相同，如下：

 
Hello world 1
Hello world 2
Hello world 3

虽然移植工作今年 7 月份才向外界透露，但 GE 能源集团的团队在一年之前——也就是 2011 年 7 月——就开始了概念验证工作，有一个小团队在工作中使用了 Java 7 的早期发布版本。 团队主管、架构师 George Marrows 向 InfoQ 说到，

这非常成功，从那时起我们就为产品发布版本而努力了。我们编写了 Magik 语言的解析器、编译器和运行时，集成了我们的大多数 C 库，并且使用 Java2D 编写了一个全新的图形子系统，所有新设计的组件都与现有系统高度兼容。

移植尚不彻底，不过移植版本已经能够运行完整的应用程序。最关键的是，考虑到 GE 能源集团的合作伙伴与客户所编写的数百万行 Magik 代码，移植版本的目标是完全兼容 MagikSF 版本，开发者只需要简单地在 JVM 移植版本上重新编译 Magik 源代码。Marrows 对我们说，“我们确信，我们的语言实现与 MagikSF 非常非常接近，我们的库支持也做得非常好，而且随着运行的 Magik 代码越来越多以及不断修复不兼容的地方，改进也在持续进行。”

正如你所预料的那样，考虑到 Magik 的动态类型系统，移植版本大量使用了 Java 7 的 invokedynamic 字节码指令。Marrows 说到，

我们大量使用了 invokedynamic，不仅是在明显的方法分派（method dispatch）中，在将复杂字面量绑定到其使用位置以及解析全局变量时也有所应用。Duncan MacGregor 在团队中负责这项工作——使用 invokedynamic，他一度发现几乎每周都有性能改进。

invokeDynamic 和 java.lang.invoke 的使用体验非常好。我们可以将其看做 JVM JIT 编译器方法内联功能的一个 API，就这一点而言，它非常出色。我们惊喜地看到，自从去年 Java 7 的第一个版本发布以来，几乎每次更新都能带来一些性能改进；而且看起来我们还可以从 Java 8 的“lambda form”工作中继续获得改进。

从技术角度看，JVM 的很多功能 MagikSF 是不支持的，比如

• MagikSF 是解释型的，而 JVM 支持 JIT 编译。
• MagikSF 使用的是绿色线程，而 JVM 使用原生线程。
• MagikSF 只支持 32 位，而 JVM 也支持 64 位。
• MagikSF 有自己的垃圾收集器，其垃圾收集器是分代的，但并非并发垃圾收集器；而在 Hotspot 虚拟机中，Java 支持多种垃圾收集器，大多是并发收集器。

当然，像 Oracle 和 IBM 等大型软件厂商所贡献的大量资源和专家经验也让 JVM 获益良多。

Marrows 的团队看到的性能改进结果令人印象深刻：在他们运行的大多数基准测试中，Java 移植版本的速度已经有所超越，有些情况下性能改进高达 30 倍。就像 Marrows 所指出的那样，随着时间的推移，invokeDynamic 和 JVM 的性能不断改进，他们的项目也相应获益，诸如在 Java 7 update 9 上要比在 Java 7 update 2 上执行得更好。更重要的是，作为 Java 8 Lambda 项目的一部分，Oracle 重新设计了 invokeDynamic；而且这一版本正在被向后移植到 Java 7 中（按照计划，该特性将包含在即将发布的 update 12 中）。尽管 Marrows 告诉我们，有些代码实例表明，相对于 update 9，在 update 12 上运行当前测试构建时性能有些劣化，但是在很多情况下新版本会快得多；这点他们会与 Oracle 的团队讨论。到目前为止，Marrows 的团队从 Oracle，特别是 JSR 292 专家组的 Rémi Forax 那里得到了极大的支持，Rémi Forax “帮助我们开始使用 JSR 292，而且在 MLVM（multi-language virtual machine）邮件列表中，他是一位不知疲倦的贡献者”。

虽然最初没有相应计划，但团队现在还是通过混用 JNI 和 Java 2D 的方式移植了图形系统——“将 JNI 与 C 库继承，可以访问我们的数据库并执行优化的几何与其他计算。Java 2D 渲染贴图和 UI。”

该团队最终实现的从 Java 到 Magik 的内置的互操作还相当不错，Java 2D 所支持的图形系统中大量使用了这一特性。比如：

 
def_slotted_exemplar(
 :line_style,
   { { :colour, colour } },
   { :simple_style_mixin},
{:|com.gesmallworld.magik.commons.drawingsurface.LineStyle|})
$ 
_private _method line_style.|getColour|()
  >> .colour
_endmethod

|getColour|中的竖线用于保留 Java 代码里的大小写，因为 Magik 是不区分大小写的。

而从 Magik 到 Java 的互操作就不是那么方便了，需要开发者编写包装代码。

 
public class Char16Vector {
   @MagikInitialiser
   public static void exposeThisClass() {
       //Expose an instance of this class to Magik
   }
   @MagikMethod(name="nth()")
   public Char16Vector nth( Integer index ) {
       return new Char16Vector(value.substring(index-1, index));
   }
}

Nashorn 是 Oracle 的新 JavaScript 实现。利用 Dynalink 库，它能够更清晰地实现该功能。Jim Laskey 在其博客上提供了一个很好的例子，通过 Twitter4J 库，使用 Nashorn 与 Twitter 交互，可以很好地实现上述功能。Marrows 告诉我们，Dynalink 就是他和团队想要看到的东西。

除了能够使用 Java 虚拟机之外，该团队发现跑在 Java 平台上还有其他的优点。Marrows 在 JavaOne Brazil 大会上提到，能够接近 Java 开发者并使用 Java 类库，这也是优势。此外他告诉我们，

…我们非常欣赏 JVM 带来的力量和灵活性，这能够支持我们未来所要进行的任何改进。

更一般的意义是，我们趁此机会简化并替换了我们迄今为止所开发的 MagikSF 环境的某些部分，如图形支持和文件 I/O 等。我们认为这种事情以后做的话，工作量只会多不会少。

JVM 上的语言越来越多，Magik 就是其中之一，其他还包括 Groovy、Jruby 和 Nashorn 等，这些语言都用到了 invokeDynamic 指令。JSR 292 真正帮助 JVM 成为一种通用的编程语言环境。

参考英文原文： GE Energy Uses InvokeDynamic to Bring Magik to the JVM