¿Por qué la JVM todavía no admite la optimización de llamadas finales?

Dos años después de does-the-jvm-prevent-tail-call-optimizations , parece haber una implementación de prototipo y MLVM ha incluido la característica como "proto 80%" desde hace algún tiempo.

¿No hay un interés activo por parte de Sun / Oracle en admitir llamadas de cola o es solo que las llamadas de cola están "[...] predestinadas a ocupar el segundo lugar en cada lista de prioridades de funciones [...]" como se menciona en la JVM Cumbre de Idiomas ?

Me interesaría mucho si alguien hubiera probado una compilación de MLVM y pudiera compartir algunas impresiones de lo bien que funciona (si es que funciona).

Actualización: tenga en cuenta que algunas máquinas virtuales como Avian admiten llamadas de cola adecuadas sin ningún problema.

Diagnóstico de código Java: Mejorar el rendimiento de su código Java ( alt ) explica por qué la JVM no admite la optimización de llamadas finales.

Pero aunque se sabe cómo transformar automáticamente una función recursiva de cola en un bucle simple, la especificación de Java no requiere que se realice esta transformación. Presumiblemente, una de las razones por las que no es un requisito es que, en general, la transformación no se puede realizar de forma estática en un lenguaje orientado a objetos. En cambio, la transformación de una función recursiva de cola a un bucle simple debe realizarse dinámicamente mediante un compilador JIT.

Luego da un ejemplo de código Java que no se transforma.

Entonces, como muestra el ejemplo del Listado 3, no podemos esperar que los compiladores estáticos realicen la transformación de la recursividad de la cola en el código Java mientras preservan la semántica del lenguaje. En cambio, debemos confiar en la compilación dinámica por parte del JIT. Dependiendo de la JVM, el JIT puede o no hacer esto.

Luego proporciona una prueba que puede utilizar para averiguar si su JIT hace esto.

Naturalmente, dado que se trata de un documento de IBM, incluye un enchufe:

Ejecuté este programa con un par de SDK de Java y los resultados fueron sorprendentes. La ejecución en Sun's Hotspot JVM para la versión 1.3 revela que Hotspot no realiza la transformación. En la configuración predeterminada, el espacio de la pila se agota en menos de un segundo en mi máquina. Por otro lado, la JVM de IBM para la versión 1.3 ronronea sin problemas, lo que indica que transforma el código de esta manera.

Una razón que he visto en el pasado para no implementar el TCO (y que se considera difícil) en Java es que el modelo de permisos en la JVM es sensible a la pila y, por lo tanto, las llamadas finales deben manejar los aspectos de seguridad.

Creo que Clements y Felleisen [1] [2] demostraron que esto no es un obstáculo y estoy bastante seguro de que el parche MLVM mencionado en la pregunta también lo trata.

Me doy cuenta de que esto no responde a su pregunta; simplemente agregando información interesante.

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

Quizás ya sepa esto, pero la característica no es tan trivial como puede parecer, ya que el lenguaje Java realmente expone el seguimiento de la pila al programador.

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

Aunque tiene una "llamada de cola", es posible que no se optimice. (Si está optimizado, aún requiere la contabilidad de toda la pila de llamadas, ya que la semántica del programa se basa en ella).

Básicamente, esto significa que es difícil admitir esto sin dejar de ser compatible con versiones anteriores.

Java es el lenguaje menos funcional que puedas imaginar (bueno, de acuerdo, ¡ quizás no !) Pero esto sería una gran ventaja para los lenguajes JVM, como Scala , que lo son.

Mis observaciones son que hacer de la JVM una plataforma para otros lenguajes nunca pareció estar en la parte superior de la lista de prioridades para Sun y supongo que ahora para Oracle.