Предотвращает ли JVM оптимизацию хвостовых вызовов?

Question

Предотвращает ли JVM оптимизацию хвостовых вызовов?

90

Я видел эту цитату на вопрос: Какой хороший функциональный язык для создания веб-сервиса?

Scala, в частности, не поддерживает исключение хвостового вызова, кроме саморекурсивных функций, что ограничивает виды композиции, которые вы можете сделать (это фундаментальное ограничение JVM).

Это правда? Если да, то что это такое о JVM, которая создает это фундаментальное ограничение?

Jason Dagit 19 сен. 2008, в 22:53

Источник

Теги:

java

scala

jvm

tail-recursion

5 ответов

28

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

Таким образом, JVM не может поддерживать языки функционального программирования производственного качества, пока Sun не реализует хвостовые вызовы в самом JVM. Они обсуждают это в течение многих лет, но я сомневаюсь, что они когда-либо будут реализовывать хвостовые звонки: это будет очень сложно, потому что они преждевременно оптимизировали свою виртуальную машину до внедрения таких базовых функций, а усилия Sun сильно ориентированы на динамические языки, а не на функциональные языки.

Следовательно, существует очень сильный аргумент в пользу того, что Scala не является реальным функциональным языком программирования: эти языки рассматривают хвостовые вызовы как важную функцию, поскольку схема была впервые введена более 30 лет назад.

Jon Harrop 06 нояб. 2008, в 03:13

4

Hence there is a very strong argument that Scala is not a real functional programming language - аргумент на самом деле довольно слабый. Конечно, tail calls [as] an essential feature , и хорошо, если базовое оборудование (или виртуальный компьютер) поддерживает его напрямую. Но это детали реализации.
Ingo 14 нояб. 2011, в 17:02
8

@Ingo: только если вы не считаете, что переполнение стека в вашей программе во время выполнения замечено пользователем как серьезная проблема. Согласно его трекеру ошибок, даже сам компилятор Scala страдает от переполнения стека. Так что даже самые опытные разработчики Scala все еще ошибаются ...
Jon Harrop 16 нояб. 2011, в 12:14
7

Можно быть защитником, скажем, F #. Но я уже давно (даже годы назад в usenet) отмечал вашу враждебность ко всему, что не является F #, и все же ваши разработки показывают, что вы не знаете, о чем говорите. Как здесь: ваш аргумент выглядит так, что язык, на котором я могу написать программу, которая прерывает работу с переполнением стека, не является функциональным? Но нельзя ли привести такой же аргумент в отношении языков, где я могу спровоцировать переполнение кучи? Следовательно, сам святой F # не будет считаться функциональным.
Ingo 16 нояб. 2011, в 12:20
0

@Ingo: «Ваш аргумент, похоже, заключается в том, что язык, на котором я могу написать программу, которая прерывает работу с переполнением стека, не является функциональным». Напротив, вы можете писать программы практически на всех функциональных языках, которые переполняют стек, например Scheme, OCaml, F #, Haskell.
Jon Harrop 18 нояб. 2011, в 23:56
0

@Ingo: «Но нельзя ли сделать такой же аргумент для языков, где я могу спровоцировать переполнение кучи? Следовательно, само по себе святое F # не будет считаться функциональным». По этой классификации никакие языки не будут «функциональными». Такие классификации не очень полезны. Формально информационное наполнение нулевое ...
Jon Harrop 18 нояб. 2011, в 23:59
0

Так в чем же заключается разница, которая делает Scala предположительно не функциональной?
Ingo 19 нояб. 2011, в 18:48
7

@Ingo: Некоторые идиомы в функциональном программировании, такие как взаимная рекурсия и стиль передачи продолжения, могут потребовать устранения хвостового вызова для работы. Без этого ваши программы будут переполнены стеком. Если язык не может надежно выполнять идиоматический функциональный код, является ли он функциональным? Ответ, как вы говорите, - это суждение, но важное различие на практике. Мартин Тройер только что опубликовал интересную запись в блоге об этом: martinsprogrammingblog.blogspot.com/2011/11/…
Jon Harrop 20 нояб. 2011, в 08:26
0

@ Инго: Например, при сопоставлении заказов на физические товары на финансовых рынках вы должны быть в состоянии удовлетворить требования к объему, такие как «достаточно ящиков, чтобы заполнить ровно одну лодку», что является проблемой ранца 0-1. Зак Брей из Trayport (лидер рынка в европейской энергетической торговле) написал этот пост в блоге, описывая, как они использовали стиль передачи продолжения для элегантного решения проблемы в F #: zbray.com/2011/11/02/…
Jon Harrop 20 нояб. 2011, в 08:29
2

тем не менее, только потому, что JVM (к сожалению, без вопросов) не может выполнять хвостовые вызовы, это не означает, что устранение хвостовых вызовов невозможно. Это так, как если бы кто-то заявил, что вычисления с плавающей запятой возможны только на компьютерах с FPU.
Ingo 20 нояб. 2011, в 18:03
0

@ Инго: Абсолютно. Я упомянул батуты в своем ответе, а также вопросы, связанные с ними.
Jon Harrop 20 нояб. 2011, в 19:36

Показать ещё 8 комментариев

20

Scala 2.7.x поддерживает оптимизацию хвостового вызова для саморекурсии (функция, вызывающая себя) конечных методов и локальных функций.

Scala 2.8 может поставляться с поддержкой библиотеки для батута, что является методом оптимизации взаимно-рекурсивных функций.

Много информации о состоянии рекурсии Scala можно найти в блоге Rich Dougherty.

Daniel C. Sobral 19 июнь 2009, в 02:23

0

Не могли бы вы обновить вопрос о текущем статусе scala?
om-nom-nom 12 апр. 2013, в 12:38
0

@ om-nom-nom AFAIK, ничего не изменилось, ни на стороне Scala, ни на стороне JVM.
Daniel C. Sobral 12 апр. 2013, в 15:38

8

В дополнение к бумаге, связанной в Lambda The Ultimate (из ссылки, представленной выше), Джон Роуз из Sun еще несколько говорит о оптимизации хвостового вызова.

http://blogs.oracle.com/jrose/entry/tail_calls_in_the_vm

Я слышал, что он может быть реализован на JVM когда-нибудь. Поддержка Tail call, среди прочего, рассматривается на машине Da Vinci.

http://openjdk.java.net/projects/mlvm/

faran 19 сен. 2008, в 22:35

0

Все источники указывают на невозможность оптимизации JVM в случае хвостовой рекурсии, но при чтении Настройка производительности Java (2003, O ' reilly) Я нашел автора, утверждающего, что он может добиться большей производительности рекурсии за счет реализации хвостовой рекурсии.

Вы можете найти его заявку на стр. 212 (поиск "хвостовой рекурсии" должен быть вторым результатом). Что дает?

fthinker 01 дек. 2010, в 15:06

0

IBM поддерживает некоторую форму TCO в своей реализации JVM (в качестве оптимизации, поэтому никаких гарантий). Возможно, авторы настройки производительности Java думали, что эта функция будет в конечном итоге реализована всеми JVM. ibm.com/developerworks/java/library/j-diag8.html
llemieng 07 фев. 2011, в 09:03

Ещё вопросы

Hence there is a very strong argument that Scala is not a real functional programming language - аргумент на самом деле довольно слабый. Конечно, tail calls [as] an essential feature , и хорошо, если базовое оборудование (или виртуальный компьютер) поддерживает его напрямую. Но это детали реализации.
@Ingo: только если вы не считаете, что переполнение стека в вашей программе во время выполнения замечено пользователем как серьезная проблема. Согласно его трекеру ошибок, даже сам компилятор Scala страдает от переполнения стека. Так что даже самые опытные разработчики Scala все еще ошибаются ...
Можно быть защитником, скажем, F #. Но я уже давно (даже годы назад в usenet) отмечал вашу враждебность ко всему, что не является F #, и все же ваши разработки показывают, что вы не знаете, о чем говорите. Как здесь: ваш аргумент выглядит так, что язык, на котором я могу написать программу, которая прерывает работу с переполнением стека, не является функциональным? Но нельзя ли привести такой же аргумент в отношении языков, где я могу спровоцировать переполнение кучи? Следовательно, сам святой F # не будет считаться функциональным.
@Ingo: «Ваш аргумент, похоже, заключается в том, что язык, на котором я могу написать программу, которая прерывает работу с переполнением стека, не является функциональным». Напротив, вы можете писать программы практически на всех функциональных языках, которые переполняют стек, например Scheme, OCaml, F #, Haskell.
@Ingo: «Но нельзя ли сделать такой же аргумент для языков, где я могу спровоцировать переполнение кучи? Следовательно, само по себе святое F # не будет считаться функциональным». По этой классификации никакие языки не будут «функциональными». Такие классификации не очень полезны. Формально информационное наполнение нулевое ...
Так в чем же заключается разница, которая делает Scala предположительно не функциональной?
@Ingo: Некоторые идиомы в функциональном программировании, такие как взаимная рекурсия и стиль передачи продолжения, могут потребовать устранения хвостового вызова для работы. Без этого ваши программы будут переполнены стеком. Если язык не может надежно выполнять идиоматический функциональный код, является ли он функциональным? Ответ, как вы говорите, - это суждение, но важное различие на практике. Мартин Тройер только что опубликовал интересную запись в блоге об этом: martinsprogrammingblog.blogspot.com/2011/11/…
@ Инго: Например, при сопоставлении заказов на физические товары на финансовых рынках вы должны быть в состоянии удовлетворить требования к объему, такие как «достаточно ящиков, чтобы заполнить ровно одну лодку», что является проблемой ранца 0-1. Зак Брей из Trayport (лидер рынка в европейской энергетической торговле) написал этот пост в блоге, описывая, как они использовали стиль передачи продолжения для элегантного решения проблемы в F #: zbray.com/2011/11/02/…
тем не менее, только потому, что JVM (к сожалению, без вопросов) не может выполнять хвостовые вызовы, это не означает, что устранение хвостовых вызовов невозможно. Это так, как если бы кто-то заявил, что вычисления с плавающей запятой возможны только на компьютерах с FPU.
@ Инго: Абсолютно. Я упомянул батуты в своем ответе, а также вопросы, связанные с ними.
Не могли бы вы обновить вопрос о текущем статусе scala?
@ om-nom-nom AFAIK, ничего не изменилось, ни на стороне Scala, ни на стороне JVM.
IBM поддерживает некоторую форму TCO в своей реализации JVM (в качестве оптимизации, поэтому никаких гарантий). Возможно, авторы настройки производительности Java думали, что эта функция будет в конечном итоге реализована всеми JVM. ibm.com/developerworks/java/library/j-diag8.html

Michael Myers · Accepted Answer · 2008-09-19T22-13-00.000Z

72

Лучший ответ

Это сообщение: Рекурсия или Итерация? может помочь.

Короче говоря, оптимизация хвостовых вызовов трудно сделать в JVM из-за модели безопасности и необходимость всегда иметь трассировку стека. Эти требования могут быть теоретически поддержаны, но для этого, вероятно, потребуется новый байт-код (см. неофициальное предложение John Rose).

В разделе всплывает ошибка Sun # 4726340, где заканчивается оценка (с 2002 года):

Я считаю, что это можно сделать, тем не менее, но это не маленькая задача.

В настоящее время в проекте Da Vinci Machine происходит некоторая работа. Статус подпроекта хвостового вызова указан как "proto 80%"; он вряд ли превратится в Java 7, но я думаю, что у него очень хороший шанс на Java 8.

Michael Myers 19 сен. 2008, в 22:13

0

Я не совсем следовал объяснениям. Я думал, что оптимизация хвостового вызова была осуществлена компилятором. Предполагая, что у вас есть функция, которую компилятор может оптимизировать с помощью хвостового вызова, вы также можете иметь эквивалентную нерекурсивную функцию, которая реализует ту же функциональность с использованием цикла, верно? Если это так, то не может это сделать компилятор. Я не в состоянии следить за зависимостью от JVM. Как это соотносится с компилятором Scheme, который генерировал собственный код i386?
Gautham Ganapathy 21 дек. 2009, в 09:22
0

Хорошо, только что видел ответ Джона ниже. Таким образом, дело не в том, что его нельзя реализовать, а в том, что его нельзя реализовать при надлежащей поддержке отладчика.
Gautham Ganapathy 21 дек. 2009, в 09:25
4

@Gautham: Мое утверждение об отладке было связано с использованием батутов в качестве обходного пути для устранения исключения хвостовых вызовов в JVM. Устранение вызовов в хвосте может и было реализовано в JVM (Арнольд Шайгофер делал это в OpenJDK, а также в LLVM), поэтому нет никаких сомнений относительно того, можно ли это сделать. CLR от Microsoft, конечно же, поддерживает устранение «хвостовых вызовов» в течение 10 лет, и выпуск F # продемонстрировал, что это изменит правила игры. Я думаю, что ответ заключается в том, что JVM давно застоялась.
Jon Harrop 23 фев. 2011, в 13:53
3

Это распространенное заблуждение и часто повторяемое оправдание, но оно неверно. В течение ряда лет было установлено, что безопасность путем проверки стека (и предоставления полезных трассировок стека) не является несовместимой с правильными вызовами хвоста. Например, см. Эту статью за 2004 год. Citeseerx.ist.psu.edu/viewdoc/… Downvoting, так как ответ неверный.
Justin Sheehy 20 май 2011, в 21:44
5

@JustinSheehy: что не так? Вопрос был: «Предотвращает ли JVM оптимизацию хвостовых вызовов?» И ответ: «Нет, но это сложно».
Michael Myers♦ 20 май 2011, в 21:54
5

Вы знаете, если в java8 это включено?
nachokk 24 апр. 2014, в 20:53
0

@nachokk Кажется, нет - stackoverflow.com/a/22866602/792238
Siddhartha 23 янв. 2015, в 18:19

Показать ещё 5 комментариев