JVMがまだテールコール最適化をサポートしていないのはなぜですか？

does-the-jvm-prevent-tail-call-optimizationsの 2年後、プロトタイプの 実装があり、MLVMはしばらくの間、この機能を「proto 80％」としてリストしています。

JVMで言及されているように、テールコールのサポートにSun / Oracleの側から積極的な関心はありませんか、それとも、テールコールが「すべての機能優先度リストで2番目に来ると運命づけられている [...]」だけです。言語サミット？

誰かがMLVMビルドをテストし、それがどれほどうまく機能するかについての印象を（もしあれば）共有できたら、私は本当に興味があります。

更新： Avianのような一部のVM は、問題なく適切な末尾呼び出しをサポートしています。

Javaコードの診断：Javaコードのパフォーマンスの向上（alt）では、JVMが末尾呼び出しの最適化をサポートしていない理由を説明しています。

しかし、末尾再帰関数を単純なループに自動的に変換する方法はよく知られていますが、Java仕様では、この変換を行う必要はありません。おそらく、それが要件ではない理由の1つは、一般に、オブジェクト指向言語では変換を静的に行うことができないためです。代わりに、末尾再帰関数から単純ループへの変換は、JITコンパイラーによって動的に行われる必要があります。

次に、変換されないJavaコードの例を示します。

したがって、リスト3の例が示すように、静的コンパイラーが言語のセマンティクスを維持しながら、Javaコードでテール再帰の変換を実行することは期待できません。代わりに、JITによる動的コンパイルに依存する必要があります。JVMに応じて、JITはこれを行う場合と行わない場合があります。

次に、JITがこれを行うかどうかを判断するために使用できるテストを提供します。

当然、これはIBMの論文なので、プラグが含まれています。

このプログラムをいくつかのJava SDKで実行したところ、驚くべき結果が得られました。Sunのバージョン1.3のHotspot JVMで実行すると、Hotspotが変換を実行しないことがわかります。デフォルトの設定では、マシンのスタックスペースが1秒未満で使い果たされます。一方、バージョン1.3用のIBMのJVMは問題なく動作し、コードがこのように変換されることを示しています。

過去にJavaにTCOを実装しない（そして、難しいと思われる）理由の1つは、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は、あなたが想像できる最も機能的な言語です（まあ、そうですね、多分そうではありません！）が、これはScalaなどのJVM言語にとっては大きな利点です。

私の見解では、JVMを他の言語のプラットフォームにすることは、Sunの優先順位リストの最上位にあるように思われることは一度もなかったようです。