给 JVM 加上长程跳转、尾调用和元组

John Rose 在今年夏季撰写了一系列文章，Charles Nutter称这些是“与JVM 未来发展方向以及一系列新版Java 潜在变化相关的令人兴奋的文章。”虽然John 确实谈到对Java 语言的影响，但文中的重点是虚拟机。这些改进对于在JVM 中为其他语言提供支持来说都是非常重要的，包括函数性语言和动态语言在内。

在文章的开头，John Rose描述了长程跳转（longjump）特性（或称为非本地退出，non-local exit），这项特性使在Java 语言中实现闭包成为可能。如果给异常处理机制加上预分配（如克隆）的跟踪栈，就有可能实现非本地退出，而不必为了流程控制支付高昂的异常处理的代价。如果实现得好，非本地退出的代价可以低于本地退出/ 返回（return）的3 倍，并能够被优化成机器级的goto 指令。在Java 7 的一个版本中，就用了这种方法来优化Object.clone() 的执行成本。

接下来，John 阐述了 JVM 中的尾调用（tail call）：即以一种明确的方式来来压缩尾递归的能力（“硬尾调用”），或仅作为一种编译器最优化（“软尾调用”）。这篇文章引起了对实现方法和用途的热烈讨论，不过尾调用对 JVM 上的函数性语言（或具备某些函数性特征的语言）肯定有所帮助，也会有利于从 invokedynamic (JSR-292) 得益的动态语言：

尾调用也会影响到 invokedynamic。硬尾调用让你在实现动态调用上有更多的选择：你可以转向到一段负责派发的分支例程，该例程随后会以尾调用返回到正常的例程上。（实际上，这就是 java.lang.reflect.Method.invoke 目前的工作原理，至少在返回值没有被装箱的情况下是如此。）因为 Scheme 是一种动态语言，所以尾调用与 JSR 292 有一点关系。

最后，John 谈到了元组（Tuple）。他翻出了早在 2004 年就提出的一个提议，里面描述了“纯粹的”元组类型（简单元组）和具备元组语义的值类（value class），这种值类不需要记得它的类型身份（即成为标记元组，tagged tuples）。元组也意味着支持具有多个返回值的方法。再一次，重点在于 JVM 而不是 Java 语言是很清楚的：

加上了元组特性的语言，很可能会在一组具有类型的值，以及指向这些值所在堆对象的引用之间提供规范的翻译。比方说，每个值类很可能都有一个构造器，其参数签名就是相应的标记元组。元组很可能被实现成堆中的固定长度的对象数组，或者是不可变的泛型工具类（generic immutable utility class），里面包含着装箱后的基本类型值成员（就像 varargs 中一样）。

这篇文章的讨论也一样很热烈，John 在讨论中回应说：

实际上在 Java 语言中加入值类会遇到困难的设计问题，正如你清楚指出的那样。我写此文的意图是指出，在 JVM 中添加元组是非常简单的，并且不需要解决语言设计方面的问题。

你对这些提议有没有共鸣呢？你是更想看到 JVM 增加对其他语言的支持，还是 Java 语言的演进？还是说这两个目标并没有冲突？ InfoQ 会继续跟踪这些主题的最新发展。

看英文原文： Longjumps, Tailcalls, Tuples for the JVM