Dlaczego maszyna JVM nadal nie obsługuje optymalizacji połączeń końcowych?

Wydaje się, że dwa lata po optymalizacji jvm -zapobiega-ogonowi-wywołania , pojawiła się prototypowa implementacja i MLVM od jakiegoś czasu określa tę funkcję jako „proto 80%”.

Czy po stronie Sun / Oracle nie ma aktywnego zainteresowania wspieraniem wywołań końcowych, czy po prostu wywołania końcowe mają „[...] zająć drugie miejsce na każdej liście priorytetów funkcji [...]”, jak wspomniano na JVM Szczyt językowy ?

Byłbym bardzo zainteresowany, gdyby ktoś przetestował kompilację MLVM i mógł podzielić się wrażeniami z tego, jak dobrze działa (jeśli w ogóle).

Aktualizacja: Zwróć uwagę, że niektóre maszyny wirtualne, takie jak Avian, obsługują prawidłowe wywołania końcowe bez żadnych problemów.

Diagnozowanie kodu Java: zwiększanie wydajności kodu Java ( alt ) wyjaśnia, dlaczego maszyna JVM nie obsługuje optymalizacji wywołań końcowych.

Ale chociaż dobrze wiadomo, jak automatycznie przekształcić funkcję rekurencyjną ogonową w prostą pętlę, specyfikacja Java nie wymaga wykonania tej transformacji. Przypuszczalnie jednym z powodów, dla których nie jest to wymagane, jest to, że generalnie transformacja nie może być wykonana statycznie w języku zorientowanym obiektowo. Zamiast tego transformacja z rekurencyjnej funkcji ogonowej do prostej pętli musi być wykonywana dynamicznie przez kompilator JIT.

Następnie podaje przykład kodu Java, który nie zostanie przekształcony.

Tak więc, jak pokazuje przykład z Listingu 3, nie możemy oczekiwać, że statyczne kompilatory wykonają transformację rekurencji ogona w kodzie Javy, zachowując semantykę języka. Zamiast tego musimy polegać na dynamicznej kompilacji przez JIT. W zależności od JVM zespół JIT może to zrobić lub nie.

Następnie daje test, którego możesz użyć, aby dowiedzieć się, czy Twój JIT to robi.

Oczywiście, ponieważ jest to papier IBM, zawiera wtyczkę:

Uruchomiłem ten program z kilkoma pakietami Java SDK i wyniki były zaskakujące. Uruchomienie na maszynie wirtualnej Hotspot firmy Sun w wersji 1.3 ujawnia, że ​​Hotspot nie wykonuje transformacji. Przy ustawieniach domyślnych miejsce na stosie wyczerpuje się na moim komputerze w mniej niż sekundę. Z drugiej strony JVM IBM dla wersji 1.3 mruczy bez problemu, wskazując, że dokonuje transformacji kodu w ten sposób.

Jednym z powodów, dla których widziałem w przeszłości, że nie implementowałem TCO (i jest to postrzegane jako trudne) w Javie, jest to, że model uprawnień w JVM jest wrażliwy na stos, a zatem wywołania końcowe muszą obsługiwać aspekty bezpieczeństwa.

Uważam, że Clements i Felleisen [1] [2] wykazali, że nie jest to przeszkodą i jestem prawie pewien, że łatka MLVM wspomniana w pytaniu również sobie z tym radzi.

Zdaję sobie sprawę, że to nie odpowiada na twoje pytanie; po prostu dodając interesujące informacje.

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

Być może już to wiesz, ale funkcja nie jest tak trywialna, jak mogłoby się wydawać, ponieważ język Java w rzeczywistości udostępnia programiście ślad stosu.

Rozważ następujący program:

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

Nawet jeśli ma to wywołanie ogonowe, może nie zostać zoptymalizowane. (Jeśli jest zoptymalizowany, nadal wymaga prowadzenia księgowości całego stosu wywołań, ponieważ opiera się na nim semantyka programu).

Zasadniczo oznacza to, że trudno jest to wspierać, będąc nadal kompatybilnym wstecz.

Java jest najmniej funkcjonalnym językiem, jaki można sobie wyobrazić (no dobra, może nie !), Ale byłaby to wielka zaleta w przypadku języków JVM, takich jak Scala .

Z moich obserwacji wynika, że ​​uczynienie z JVM platformy dla innych języków nigdy nie wydawało się być na szczycie listy priorytetów dla Sun, a teraz chyba dla Oracle.