Perché la JVM continua a non supportare l'ottimizzazione della chiamata finale?

Due anni dopo le ottimizzazioni-jvm-prevent-tail-call , sembra esserci un'implementazione del prototipo e MLVM ha elencato la funzionalità come "proto 80%" da qualche tempo.

Non c'è alcun interesse attivo da parte di Sun / Oracle nel supportare le tail call o è solo che le tail call sono "[...] destinate a venire al secondo posto in ogni lista di priorità delle funzionalità [...]" come menzionato alla JVM Summit linguistico ?

Sarei davvero interessato se qualcuno avesse testato una build MLVM e potesse condividere alcune impressioni su come funziona (se non del tutto).

Aggiornamento: si noti che alcune VM come Avian supportano chiamate di coda appropriate senza problemi.

Diagnosi del codice Java: Migliorare le prestazioni del codice Java ( alt ) spiega perché JVM non supporta l'ottimizzazione della chiamata finale.

Ma sebbene sia ben noto come trasformare automaticamente una funzione ricorsiva di coda in un semplice ciclo, la specifica Java non richiede che questa trasformazione venga eseguita. Presumibilmente, una delle ragioni per cui non è un requisito è che, in generale, la trasformazione non può essere eseguita staticamente in un linguaggio orientato agli oggetti. Invece, la trasformazione da funzione ricorsiva di coda a ciclo semplice deve essere eseguita dinamicamente da un compilatore JIT.

Quindi fornisce un esempio di codice Java che non si trasformerà.

Quindi, come mostra l'esempio nel Listato 3, non possiamo aspettarci che i compilatori statici eseguano la trasformazione della ricorsione in coda sul codice Java preservando la semantica del linguaggio. Invece, dobbiamo fare affidamento sulla compilazione dinamica da parte del JIT. A seconda della JVM, il JIT può farlo o meno.

Quindi fornisce un test che puoi usare per capire se il tuo JIT lo fa.

Naturalmente, trattandosi di un documento IBM, include un plug:

Ho eseguito questo programma con un paio di Java SDK ei risultati sono stati sorprendenti. L'esecuzione su Sun's Hotspot JVM per la versione 1.3 rivela che Hotspot non esegue la trasformazione. Con le impostazioni predefinite, lo spazio dello stack si esaurisce in meno di un secondo sulla mia macchina. D'altra parte, la JVM di IBM per la versione 1.3 fa le fusa senza problemi, indicando che trasforma il codice in questo modo.

Uno dei motivi che ho visto in passato per non implementare il TCO (ed è considerato difficile) in Java è che il modello di autorizzazione nella JVM è sensibile allo stack e quindi le chiamate in coda devono gestire gli aspetti di sicurezza.

Credo che Clements e Felleisen [1] [2] abbiano dimostrato che questo non è un ostacolo e sono abbastanza sicuro che anche la patch MLVM menzionata nella domanda lo affronti.

Mi rendo conto che questo non risponde alla tua domanda; aggiungendo solo informazioni interessanti.

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

Forse lo sai già, ma la funzionalità non è così banale come potrebbe sembrare poiché il linguaggio Java espone effettivamente la traccia dello stack al programmatore.

Considera il seguente programma:

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

Anche se ha un "richiamo di coda", potrebbe non essere ottimizzato. (Se è ottimizzato, richiede comunque la contabilità dell'intero stack di chiamate poiché la semantica del programma si basa su di esso.)

Fondamentalmente, questo significa che è difficile supportarlo pur essendo compatibile con le versioni precedenti.

Java è il linguaggio meno funzionale che potresti immaginare (beh, OK, forse no !) Ma questo sarebbe un grande vantaggio per i linguaggi JVM, come Scala , che lo sono.

Le mie osservazioni sono che rendere la JVM una piattaforma per altri linguaggi non è mai sembrato essere in cima alla lista delle priorità per Sun e immagino, ora per Oracle.