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

Какие изменения в JVM будут наиболее полезны для компилятора Scala и времени выполнения?

Динамические языки в значительной степени выиграют от внедрения кода байта InvokeDynamic, запланированного для поступления в JVM 7, и Scala, вероятно, выиграют от рекурсии хвоста (не уверен, что он появится в JVM 8 или новее).

Какие другие изменения могли бы использовать Scala с его нынешним набором функций в JVM? Являются ли эти изменения на горизонте?

В частности, существуют ли изменения в JVM, которые улучшили бы производительность с помощью замыканий и функций-как-быстей?

ОТВЕТЫ

Ответ 1

В принципе, все, что Джон Роуз занимался:)

  • Fixnums - Чтобы устранить стоимость примитивов бокса/распаковки.

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

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

  • Инъекция интерфейса - Упростите состав mixin и реализацию ролей, а также устраните необходимость создания некоторых промежуточных классов и создания структурные типы возможны без отражения во многих случаях.

  • Оптимизация хвостовых вызовов - должно быть без проблем:)

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

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

Ответ 2

Существует несколько особенностей Scala, которые будут лучше реализованы в JVM, например:

  • Общие, доступные во время выполнения. В настоящий момент scalac сохраняет типы дженериков в виде скрытых полей (если рассматриваемый класс является классом case). Это делает дженерики в случае, если классы неоправданно дороги, хотя.

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

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

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

EDIT: добавлена ​​дисперсия объявления-сайта.

Ответ 3

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

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

Ответ 4

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

MethodHandles почти как исполняющая форма "Reflection done right".

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