Por que a JVM ainda não oferece suporte à otimização de chamada final?

Dois anos após as otimizações de faz-the-jvm-prevent-tail-call-call , parece haver uma implementação de protótipo e o MLVM listou o recurso como "proto 80%" há algum tempo.

Não há interesse ativo da parte da Sun / Oracle em apoiar chamadas finais ou apenas que as chamadas finais estão "[...] fadadas a ficar em segundo lugar em cada lista de prioridade de recursos [...]", conforme mencionado na JVM Language Summit ?

Eu estaria realmente interessado se alguém testou uma compilação de MLVM e pudesse compartilhar algumas impressões de como ela funciona bem (se funcionar).

Atualização: Observe que algumas VMs, como a Avian, oferecem suporte a chamadas de cauda adequadas sem problemas.

Diagnosticando Código Java: Melhorando o Desempenho de Seu Código Java ( alt ) explica por que a JVM não oferece suporte à otimização de chamada final.

Mas embora seja bem conhecido como transformar automaticamente uma função recursiva de cauda em um loop simples, a especificação Java não exige que essa transformação seja feita. Presumivelmente, um motivo pelo qual não é um requisito é que, em geral, a transformação não pode ser feita estaticamente em uma linguagem orientada a objetos. Em vez disso, a transformação da função recursiva de cauda em loop simples deve ser feita dinamicamente por um compilador JIT.

Em seguida, dá um exemplo de código Java que não se transforma.

Portanto, como mostra o exemplo da Listagem 3, não podemos esperar que os compiladores estáticos realizem a transformação da recursão final no código Java enquanto preservam a semântica da linguagem. Em vez disso, devemos contar com a compilação dinâmica pelo JIT. Dependendo do JVM, o JIT pode ou não fazer isso.

Em seguida, ele fornece um teste que você pode usar para descobrir se seu JIT faz isso.

Naturalmente, como este é um artigo da IBM, inclui um plugue:

Eu executei este programa com alguns SDKs Java e os resultados foram surpreendentes. Executar no Hotspot JVM da Sun para a versão 1.3 revela que o Hotspot não realiza a transformação. Nas configurações padrão, o espaço da pilha se esgota em menos de um segundo na minha máquina. Por outro lado, a JVM da IBM para a versão 1.3 ronrona sem problemas, indicando que ela transforma o código dessa maneira.

Um motivo que vi no passado para não implementar o TCO (e isso é visto como difícil) em Java é que o modelo de permissão na JVM é sensível à pilha e, portanto, as chamadas finais devem lidar com os aspectos de segurança.

Acredito que Clements e Felleisen [1] [2] demonstraram que isso não é um obstáculo e tenho quase certeza de que o patch MLVM mencionado na pergunta também lida com isso.

Sei que isso não responde à sua pergunta; apenas adicionando informações interessantes.

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

Talvez você já saiba disso, mas o recurso não é tão trivial quanto pode parecer, já que a linguagem Java realmente expõe o rastreamento da pilha para o programador.

Considere o seguinte programa:

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

Mesmo que isso tenha uma "chamada de cauda", pode não ser otimizado. (Se for otimizado, ainda requer a manutenção de toda a pilha de chamadas, uma vez que a semântica do programa depende disso.)

Basicamente, isso significa que é difícil suportar isso enquanto ainda é compatível com versões anteriores.

Java é a linguagem menos funcional que você poderia imaginar (bem, OK, talvez não !), Mas isso seria uma grande vantagem para linguagens JVM, como Scala , que são.

Minhas observações são que tornar a JVM uma plataforma para outras linguagens nunca pareceu estar no topo da lista de prioridades da Sun e, agora, da Oracle, acho.