Почему JVM до сих пор не поддерживает оптимизацию хвостового вызова?

Спустя два года после оптимизации «делает-jvm-prevent-tail-call-call» , похоже, существует реализация прототипа, и MLVM уже некоторое время указывает эту функцию как «proto 80%».

Нет ли активный интерес со стороны компании Sun / Oracle в поддержку хвостовых вызовов или это просто , что хвостовые вызовы «[...] суждено прийти на втором месте в каждом списке приоритетов особенность [...]» , как указано в JVM Языковой саммит ?

Мне было бы очень интересно, если бы кто-нибудь протестировал сборку MLVM и мог бы поделиться некоторыми впечатлениями о том, насколько хорошо она работает (если вообще).

Обновление: обратите внимание, что некоторые виртуальные машины, такие как Avian, поддерживают правильные хвостовые вызовы без каких-либо проблем.

Диагностика кода Java: повышение производительности кода Java ( alt ) объясняет, почему JVM не поддерживает оптимизацию хвостового вызова.

Но хотя хорошо известно, как автоматически преобразовывать хвостовую рекурсивную функцию в простой цикл, спецификация Java не требует этого преобразования. По-видимому, одна из причин, по которой это не является обязательным требованием, заключается в том, что в целом преобразование не может быть выполнено статически на объектно-ориентированном языке. Вместо этого преобразование от хвостовой рекурсивной функции к простому циклу должно выполняться динамически JIT-компилятором.

Затем он дает пример кода Java, который не трансформируется.

Итак, как показывает пример в листинге 3, мы не можем ожидать, что статические компиляторы выполнят преобразование хвостовой рекурсии в Java-коде при сохранении семантики языка. Вместо этого мы должны полагаться на динамическую компиляцию JIT. В зависимости от JVM JIT может это делать, а может и не делать.

Затем он дает тест, который вы можете использовать, чтобы выяснить, делает ли это ваша JIT.

Естественно, поскольку это статья IBM, она включает в себя заглушку:

Я запустил эту программу с парой Java SDK, и результаты были удивительными. Запуск JVM Sun Hotspot для версии 1.3 показывает, что Hotspot не выполняет преобразование. При настройках по умолчанию пространство стека на моем компьютере исчерпывается менее чем за секунду. С другой стороны, JVM IBM для версии 1.3 мурлычет без проблем, указывая на то, что она действительно преобразует код таким образом.

Одна из причин, по которой я видел в прошлом отказ от реализации TCO (и это считается трудным) в Java, заключается в том, что модель разрешений в JVM чувствительна к стеку, и поэтому хвостовые вызовы должны обрабатывать аспекты безопасности.

Я считаю, что Клементс и Фелляйзен [1] [2] показали, что это не является препятствием, и я почти уверен, что патч MLVM, упомянутый в вопросе, также имеет дело с этим.

Я понимаю, что это не ответ на ваш вопрос; просто добавляю интересную информацию.

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

Возможно, вы уже это знаете, но эта функция не так тривиальна, как может показаться, поскольку язык Java фактически предоставляет программисту трассировку стека.

Рассмотрим следующую программу:

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

Несмотря на то, что это имеет «хвостовой вызов», его нельзя оптимизировать. (Если она будет оптимизирована, она по- прежнему требует бухгалтерии всего вызова стека поскольку семантике программа опирается на него.)

По сути, это означает, что это сложно поддерживать, оставаясь при этом обратно совместимой.

Java - наименее функциональный язык, который вы можете себе представить (ну, ладно, возможно, нет !), Но это было бы большим преимуществом для языков JVM, таких как Scala , которые есть.

По моим наблюдениям, превращение JVM в платформу для других языков никогда не было на первом месте в списке приоритетов Sun и, я полагаю, теперь Oracle.