Чому Java взагалі не має оптимізації для хвостової рекурсії?

З того, що я прочитав: Причина полягає в тому, що не просто визначити, який метод насправді буде називатися так, як ми маємо спадщину.

Однак чому Java принаймні не має оптимізацію хвостових рекурсій для статичних методів і не застосовує належний спосіб викликати статичні методи за допомогою компілятора?

Чому Java взагалі не має підтримки для рекурсії хвоста?

Я не впевнений, чи є тут взагалі якісь труднощі.

Щодо запропонованого дубліката , як пояснив Йорг W Міттаг ¹ :

• Інше питання задається про TCO, це про TRE. TRE набагато простіше, ніж TCO.
• Крім того, інше питання задає питання про обмеження, які JVM накладає на мовні реалізації, які бажають компілювати до JVM, це питання задає Java, яка є однією мовою, яка не обмежена JVM, оскільки специфікацію JVM можна змінити ті ж люди, які розробляють Java.
• І, нарешті, у JVM немає навіть обмежень щодо TRE, тому що в JVM є внутрішній метод GOTO, який є усім необхідним для TRE

¹ _{Додано форматування для виклику очок.}

Як пояснив у цьому відео Брайан Гец (Java Language Architect в Oracle) :

у класах jdk [...] існує ряд методів, що залежать від безпеки, які покладаються на підрахунок кадрів стека між кодом бібліотеки jdk та кодом виклику, щоб з'ясувати, хто їх викликає.

Все, що змінило кількість кадрів на стеку, це порушить і спричинить помилку. Він визнає, що це було дурною причиною, і тому розробники JDK відтоді замінили цей механізм.

Далі він зазначає, що це не пріоритет, а рецидиви хвоста

врешті-решт закінчиться.

Примітка Це стосується HotSpot та OpenJDK, інші VM можуть відрізнятися.

У Java немає оптимізації хвостових викликів з тієї самої причини, чому у більшості імперативних мов немає. Імперативні петлі є кращим стилем мови, і програміст може замінити хвостову рекурсію імперативними петлями. Складність не варта для функції, використання якої не відштовхується від стилю.

Ця річ, коли програмісти хочуть іноді писати у FP-стилі інакше вкрай необхідними мовами, увійшли в моду лише протягом останніх 10 років або близько того, після того, як комп'ютери почали масштабувати в ядрах замість ГГц. Навіть зараз це не так популярно. Якби я запропонував замінити імперативну петлю на рецидиві хвоста на роботі, половина рецензентів на код посміялася б, а друга половина видала блуканий вигляд. Навіть у функціональному програмуванні ти, як правило, уникаєш хвостової рекурсії, якщо інші конструкції, такі як функції вищого порядку, не підходять чітко.

У Java немає оптимізації високих викликів, оскільки JVM не має байт-коду для хвостових викликів (до деякого статично невідомого вказівника функції, наприклад, методу в деяких vtable).

Це схоже на соціальні (а може бути і технічні) причини, додавання нової операції байт-коду в JVM (що зробило б її несумісною з попередніми версіями цього JVM) дуже важко для власника специфікації JVM.

^{Технічні причини не додавання нового байтового коду у специфікацію JVM включають той факт, що реальні реалізації JVM є надзвичайно складними програмними програмами (наприклад, через безліч оптимізацій JIT, які вони роблять).}

Хвостові дзвінки до якоїсь невідомої функції вимагають заміни поточного кадру стека на новий, і ця операція повинна знаходитися в JVM (справа не лише в зміні компілятора генерації байт-коду).

Якщо мова не має спеціального синтаксису для здійснення хвостового виклику (рекурсивний або іншим способом), і компілятор буде збиватися, коли запит хвоста вимагається, але не може бути згенерований, "необов'язковий" хвіст-виклик або хвіст-рекурсійна оптимізація призведе до ситуацій, коли фрагмент коду може вимагати менше 100 байт стека на одній машині, але більше 100 000 000 байт стека на іншій. Такого різного слід вважати якісним, а не просто кількісним.

Очікується, що машини можуть мати різні розміри стека, і тому код завжди може працювати на одній машині, але дути стек на іншій. Однак, як правило, код, який буде працювати на одній машині, навіть коли стек штучно обмежений, швидше за все, буде працювати на всіх машинах із "нормальними" розмірами стека. Якщо, однак, метод, що повторює 1 000 000 глибин, є хвостовим викликом, оптимізованим на одній машині, а не на іншій, виконання на колишній машині, швидше за все, спрацює, навіть якщо його стек є незвично малим, а на останньому виходить з ладу, навіть якщо його стек незвично великий .

Я думаю, що в Java не використовується рекурсія хвостових викликів, головним чином тому, що це змінить сліди стека і, таким чином, зробить налагодження програми набагато складніше. Я думаю, що однією з головних цілей Java є дозволити програмістам легко налагоджувати свій код, а відстеження стеків має важливе значення для цього, особливо у високо об'єктно орієнтованому середовищі програмування. Оскільки ітерація може бути використана натомість, мовний комітет, мабуть, подумав, що не варто додавати хвостову рекурсію.