给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