Улучшение JVM для Scala

По сути, все, за что агитировал Джон Роуз :)

• Fixnums – для устранения затрат на упаковку/распаковку примитивов.

• Дескрипторы методов. Ускорят функции более высокого порядка и позволят JVM более эффективно их оптимизировать. Типы SAM иногда могут потребовать неудобного переключения между мономорфными и мегаморфными сайтами вызовов, что предотвращает встраивание.

• Continuations — для поддержки асинхронного/параллельного проектирования в соответствии с node.js.

• Внедрение в интерфейс – упрощает создание миксинов и реализацию ролей, а также устраняет необходимость создание некоторых промежуточных классов и создание структурных типов без отражения во многих случаях.

• Оптимизация хвостового вызова — это не проблема :)

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

Я также считаю неразумным ожидать чего-либо, что нарушило бы обратную совместимость в Java. Этого просто не будет.

Есть несколько функций Scala, которые лучше реализовать в JVM, например:

• Универсальные шаблоны, доступные во время выполнения. На данный момент scalac сохраняет типы дженериков как скрытые поля (если рассматриваемый класс является классом case). Однако это делает дженерики в классах случаев излишне дорогими.

• Декларация-сайт отклонение. Scala указывает вариантность параметров типа на сайте определения, а Java делает это на сайте вызова. Однако это вряд ли будет исправлено, поскольку это нарушит весь существующий универсальный код Java.

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

• Удаление нулевых указателей. Scala уже может обрабатывать нулевые ссылки с помощью Option[A], но из-за того, что он находится в JVM, ссылка на сам параметр может быть нулевым или его параметр может быть нулевым. Таким образом, вы не получаете гарантии ненулевого значения, как, например, в Haskell.

РЕДАКТИРОВАТЬ: добавлено отклонение от места объявления в список.

Типы значений немного помогут с точки зрения производительности для кортежей и классов case. Escape-анализ помогает немного уменьшить выделение кучи для таких объектов, но на данный момент JVM не может достаточно агрессивно встроить вызовы некоторых методов, поэтому не может исключить выделение кучи для этих небольших неизменяемых объектов. Это приводит к засорению кучи и увеличению времени выполнения в 3-4 раза.

Типы значений также помогают повысить локальность данных и сократить использование памяти. Например, в простом Array[(Int, Int)] каждая запись массива будет иметь накладные расходы в виде одного указателя + заголовка объекта. С помощью типов значений эти накладные расходы могут быть полностью устранены.

Люди часто сосредотачиваются на InvokeDynamic, не понимая, что инфраструктура MethodHandles имеет множество других преимуществ, даже если ссылки на методы, которые предоставляет MH, никогда не вызываются динамически.

MethodHandles почти как эффективная форма "правильного отражения".

Любой язык, активно использующий отражение, вполне может извлечь выгоду из использования дескрипторов методов внутри среды выполнения языка.