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

在进行了-jvm-prevent-tail-call-optimizations之后的两年，似乎有一个原型 实现，并且MLVM一段时间以来将该功能列为“ proto 80％”。

Sun / Oracle方面对支持尾部调用是否没有积极的兴趣，或者仅仅是JVM提到尾部调用“ 注定要在每个功能优先级列表上排在第二位 ”。语言峰会？

如果有人测试了MLVM构建并可以分享其运行效果的印象（如果有的话），我将非常感兴趣。

更新： 请注意，某些虚拟机（如Avian）支持正确的尾部调用，而没有任何问题。

诊断Java代码：提高Java代码的性能（alt）解释了为什么JVM不支持尾调用优化。

但是，尽管众所周知如何将尾递归函数自动转换为简单循环，但是Java规范并不要求进行这种转换。大概没有原因的一个原因是，通常，不能以面向对象的语言静态地进行转换。相反，必须由JIT编译器动态完成从尾递归函数到简单循环的转换。

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

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

然后它提供了一个测试，您可以用来确定您的JIT是否这样做。

自然，由于这是IBM论文，因此它包含一个插件：

我使用几个Java SDK运行了该程序，结果令人惊讶。在Sun的1.3版Hotspot JVM上运行后，发现Hotspot不执行转换。在默认设置下，计算机上的堆栈空间用完不到一秒钟。另一方面，IBM的1.3版JVM发出了毫无问题的提示，表明它确实以这种方式转换了代码。

过去我没有在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

也许您已经知道这一点，但是该功能并不像听起来那么简单，因为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());
    }
}

即使它有一个“尾部调用”，它也可能没有被优化。（如果它被优化，但仍需要自的程序依赖于它的语义整个调用堆栈的簿记。）

基本上，这意味着在仍然向后兼容的同时很难支持它。

Java是您可能想到的功能最少的语言（好吧，也许不是！），但这对于JVM语言（例如Scala）将是一个巨大的优势。

我的观察是，使JVM成为其他语言的平台似乎从来就不是Sun的优先事项，我想现在是Oracle。