为什么JVM还不支持尾部调用优化？

发布于 2024-09-17 08:56:31 字数 896 浏览 12 评论 0原文

两年后 does-the-jvm-prevent-tail-call-optimizations，似乎有一个原型实施和MLVM 将该功能列为“proto 80%”已有一段时间了。

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

如果有人测试了 MLVM 构建并能分享一些关于它工作效果的印象（如果有的话），我会非常感兴趣。

更新： 请注意，某些虚拟机例如 Avian< /a> 支持正确的尾部调用，没有任何问题。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

云裳 2024-09-24 08:56:31

我过去发现在 Java 中不实现 TCO（并且被认为很困难）的原因之一是 JVM 中的权限模型是堆栈敏感的，因此尾部调用必须处理安全方面的问题。

我相信 Clements 和 Felleisen [1] [2] 已经证明这不是一个障碍，而且我很确定问题中提到的 MLVM 补丁也可以解决这个问题。

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

回复收藏 0 原文

知你几分 2024-09-24 08:56:31

诊断 Java 代码：提高 Java 代码的性能 (< a href="http://web.archive.org/web/20120506085636/http://www.ibm.com/developerworks/java/library/j-diag8/index.html" rel="noreferrer">alt< /a>) 解释了为什么 JVM 不支持尾部调用优化。

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

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

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

然后它提供了一个测试，您可以用它来确定您的 JIT 是否执行此操作。

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

我和几个人一起运行了这个程序
Java SDK，结果是
奇怪。在太阳热点上运行
1.3 版本的 JVM 表明
热点不执行
转变。在默认设置下，
堆栈空间在更少的时间内耗尽
比我的机器上的一秒钟还要多。上
另一方面，IBM 的 JVM 版本 1.3
毫无问题地发出呼噜声，
表明它确实改变了
代码就是这样。

回复收藏 0 原文

嘿哥们儿 2024-09-24 08:56:31

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

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

基本上，这意味着在仍然落后的情况下很难支持这一点兼容的。

Perhaps you know this already, but the feature is not as trivial as it may sound since the Java language actually exposes the stack trace to the programmer.

Consider the following program:

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());
    }
}

Even though this has a "tail-call" it may not be optimized. (If it is optimized, it still requires book-keeping of the entire call-stack since the semantics of the program relies on it.)

Basically, this means that it's hard to support this while still being backward compatible.

回复收藏 0 原文