Чому JVM досі не підтримує оптимізацію зворотних викликів?

Через два роки після того, як робить-jvm-предотвратить-хвост-оптимізацію викликів , здається, є реалізація прототипу, і MLVM вже деякий час перелічує цю функцію як "прото 80%".

Чи немає активного інтересу з боку Sun / Oracle у підтримці хвостових викликів, чи просто, що хвостові виклики "[...] судилися виходити на друге місце у кожному списку пріоритетів функцій [...]", як згадувалося в JVM Мовний саміт ?

Мені було б дуже цікаво, якщо хтось протестував збірку MLVM і міг поділитися враженнями про те, наскільки добре це працює (якщо взагалі).

Оновлення: Зверніть увагу, що деякі віртуальні машини, такі як Avian, без проблем підтримують правильні зворотні дзвінки.

Діагностування коду Java: Покращення продуктивності коду Java ( alt ) пояснює, чому JVM не підтримує оптимізацію зворотних викликів.

Але хоча добре відомо, як автоматично перетворити хвостову рекурсивну функцію в простий цикл, специфікація Java не вимагає здійснення цього перетворення. Імовірно, одна з причин, що це не є вимогою, полягає в тому, що загалом трансформація не може бути здійснена статично об'єктно-орієнтованою мовою. Натомість перетворення з хвостово-рекурсивної функції на простий цикл має виконуватися динамічно компілятором JIT.

Потім він подає приклад коду Java, який не трансформується.

Отже, як показує приклад у лістингу 3, ми не можемо очікувати, що статичні компілятори виконуватимуть трансформацію рекурсії хвоста в коді Java, зберігаючи при цьому семантику мови. Натомість ми повинні покладатися на динамічну компіляцію JIT. Залежно від JVM, JIT може це робити, а може і не робити.

Потім він дає тест, за допомогою якого можна з’ясувати, чи робить це ваш JIT.

Звичайно, оскільки це папір IBM, він містить штекер:

Я запустив цю програму з декількома Java SDK, і результати були несподіваними. Запуск на Sun's Hotspot JVM для версії 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.