ti-enxame.com

Por que a JVM ainda não suporta a otimização de chamada de cauda?

Dois anos depois de otimizações da chamada de cauda da JVM , parece haver um protótipoimplementação e MLVM listou o recurso como "proto 80%" há algum tempo.

Não há interesse ativo do lado da Sun/Oracle em oferecer suporte a chamadas finais ou apenas as chamadas finais são "[...] destinadas a ficar em segundo lugar em todas as listas de prioridades de recursos [...] "como mencionado no JVM Language Summit ?

Eu ficaria realmente interessado se alguém testasse uma compilação do MLVM e pudesse compartilhar algumas impressões de quão bem ele funciona (se é que existe).

Atualização: Observe que algumas VMs gostam de Avian suporta chamadas de cauda adequadas sem problemas.

95
soc

Diagnosticando o Código Java: Melhorando o Desempenho do Seu Código Java) ( alt ) explica por que a JVM não suporta chamada de cauda otimização.

Porém, embora seja 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 dos motivos para não ser 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 para loop simples deve ser feita dinamicamente por um compilador JIT.

Em seguida, fornece um exemplo de código Java que não será transformado.

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

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

Naturalmente, como este é um documento da IBM, inclui um plug:

Eu executei este programa com alguns dos Java SDKs, e os resultados foram surpreendentes. A execução no JVM do Hotspot 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 acaba 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.

32
emory

Uma razão que eu vi no passado por 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 isso não foi um obstáculo demonstrado por Clements e Felleisen [1] [2] e tenho certeza de que o patch da 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
30
Alex Miller

Talvez você já saiba disso, mas o recurso não é tão trivial quanto pode parecer, pois a linguagem Java realmente expõe o rastreamento da pilha ao 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 final", pode não ser otimizado. (Se for otimizado, ainda será necessário manter a contabilidade de toda a pilha de chamadas, pois a semântica do programa depende disso.)

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

14
aioobe

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

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

12
oxbow_lakes