为什么JVM仍然不支持尾调用优化？

Question

在jvm-prevent-tail-call-optimization之后两年,似乎有一个原型 实现,MLVM已经将该功能列为"proto 80%"一段时间了.

Sun的/ Oracle方面是否没有积极的兴趣支持尾调用,或者只是尾部调用" 在每个功能优先级列表中排在第二位 [...]"如JVM所述语言峰会？

如果有人测试了MLVM构建并且可以分享它的工作原理(如果有的话),我会非常感兴趣.

更新: 请注意,像Avian这样的某些虚拟机支持正确的尾部调用,没有任何问题.

Answer 1

诊断Java代码:提高Java代码的性能(alt)解释了JVM不支持尾调用优化的原因.

但是,尽管众所周知如何将尾递归函数自动转换为简单循环,但Java规范并不要求进行此转换.据推测,不是要求的一个原因是,通常,转换不能在面向对象的语言中静态地进行.相反,从尾递归函数到简单循环的转换必须由JIT编译器动态完成.

然后给出了一个不会转换的Java代码示例.

因此,正如清单3中的示例所示,我们不能指望静态编译器在保留语言语义的同时对Java代码执行尾递归转换.相反,我们必须依靠JIT的动态编译.根据JVM,JIT可能会也可能不会这样做.

然后它给出了一个测试,您可以用它来确定您的JIT是否这样做.

当然,由于这是一篇IBM论文,它包含一个插件:

我用几个Java SDK运行了这个程序,结果令人惊讶.在Sun的Hotspot JVM上运行版本1.3显示Hotspot不执行转换.在默认设置下,堆栈空间在我的机器上耗尽不到一秒钟.另一方面,IBM的版本1.3的JVM没有问题,表明它确实以这种方式转换代码.

Answer 2

我之前看到的在Java中未实现TCO(并且被视为困难)的一个原因是JVM中的权限模型是堆栈敏感的,因此尾调用必须处理安全方面.

我相信这显示不是Clements和Felleisen [1] [2]的障碍,我很确定问题中提到的MLVM补丁也会处理它.

我意识到这不能回答你的问题; 只是添加有趣的信息.

1. http://www.ccs.neu.edu/scheme/pubs/esop2003-cf.pdf
2. http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf

Answer 3

也许您已经知道这一点,但是这个功能并不像听起来那么简单,因为Java语言实际上将堆栈跟踪暴露给程序员.

考虑以下程序:

public class Test {

    public static String f() {
        String s = Math.random() > .5 ? f() : g();
        return s;
    }

    public static String g() {
        if (Math.random() > .9) {
            StackTraceElement[] ste = new Throwable().getStackTrace();
            return ste[ste.length / 2].getMethodName();
        }
        return f();
    }

    public static void main(String[] args) {
        System.out.println(f());
    }
}

即使这有"尾调",也可能无法优化.(如果它被优化,它仍然需要整个调用堆栈的簿记,因为程序的语义依赖于它.)

基本上,这意味着在向后兼容的同时很难支持它.

Answer 4

Java是你可能想象的功能最少的语言(好吧,好吧,也许不是!)但这对于像Scala这样的JVM语言来说是一个很大的优势.

我的观察是,使JVM成为其他语言的平台似乎从未成为Sun优先级列表的首选,我想,现在对于Oracle来说.