¿Por qué la JVM todavía no soporta la optimización de tail-call?

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

Creo que Clements y Felleisen demostraron que esto no era un obstáculo [1] [2] 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 interesante información.

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

Tal vez ya lo sepa, pero la característica no es tan trivial como puede sonar, 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 esto tiene una "llamada de cola", puede que no esté optimizado. (Si está optimizado, todavía requiere llevar la contabilidad de toda la pila de llamadas ya que la semántica del programa depende de ella.)

Básicamente, esto significa que es difícil soportar esto mientras todavía ser compatible con versiones anteriores.

Java es el lenguaje menos funcional que puedas imaginar (bueno, OK, 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 ha parecido estar en la parte superior de la lista de prioridades para Sun y, supongo, ahora para Oracle.