Эта группа экспертов по будущему JVM включает Клифф Клик, Чарли Ханта и Дуга Ли.
Задан ряд интересных вопросов, и хотя я согласен с поднятыми вопросами, мне вспоминается кое-что, о чем я часто говорю; обычно простота и ремонтопригодность важнее производительности.
Q: struct, они нам нужны?
Общее обсуждение в целом их поддерживает, но Клифф Клик поднимает вопрос о том, что проблема производительности может быть решена в ближайшие пять-семь лет.
Моя точка зрения: реальная ценность структур — это способность эффективно определять типы. например, вместо использования String для «имени», длинного для «идентификатора учетной записи», BigDecimal для «цены», вы можете определять структуры этих типов и использовать эти типы в методах и классах, не беспокоясь о производительности или накладных расходах.
Вместо
Map> map = ... public Double update(String name, long accountId, double price)
ты можешь написать
Map> map = ...
public Price update(Name name, AccountId accountId, Price price)
без заботы о производительности или накладных расходах. Это не просто определение типа, так как эти поля могут быть комбинацией примитивов или, возможно, ссылкой (хотя позднее это усложнит GC)
Q: Поддержка типов значений Multi-Field, то есть шире, чем 64-битные?
Я хотел бы видеть 128-битные целые и 128-битные с плавающей запятой. Существует много вариантов более точного расчета и хранения больших значений. Текущие BigDecimal и BigInteger очень громоздки по сравнению с использованием специализированных типов, которые не элегантны, или настолько эффективны, насколько это возможно.
ИМХО, одна вещь, которая помогла бы BigDecimal и BigInteger — это предоставление операторов.
Q: Аппаратное сходство и многоядерное программирование?
Многоядерное программирование находится в диапазоне 1000 ядер в будущем. Они чувствовали, что программирование общего назначения для такого количества ядер еще не решено.
Даг Ли не очень увлекался закреплением ниток на ядрах. Неясно, почему, но, возможно, он чувствовал, что попытка решить проблему лучше всего решить другим способом.
Мое мнение: я считаю, что сродство потоков полезно только для очень специфических случаев, таких как минимизация джиттера в диапазоне от 99% до 99,99%. Если вы не обеспокоены этим, я не думаю, что сложность стоит какой-либо выгоды, которую вы увидите.
Q: Примитивы Барьера Памяти
Это будет доступно в Java 8 через встроенные функции в Unsafe, которые скрывают эти функции. Он обеспечит функциональность, которую обеспечивает C ++ v11 в новой модели памяти.
Мое мнение: из-за использования общей памяти поверх файлов, отображаемых в память, некоторые примитивы, которые работают в этом режиме, были бы очень полезны. В настоящее время я использую подмножество, которое я нашел, чтобы работать на amd64 / x64, у которого есть очевидная проблема, что он может не работать на ARM и другом оборудовании.
Q: Профили JVM
Разным системам нужны разные компромиссы и разные профили Java. Они обсудили встроенные и мобильные профили.
Мой вид: более режим реального времени или профиль был бы полезен. Тот, который может загружать классы и JIT-код более агрессивно при запуске без недостатков замедления работы кода в долгосрочной перспективе, если вы уменьшите CompileThreshold
Q: Параллельное программирование
Большая часть обсуждения была вокруг STM и HTM. Мнение о том, что STM, возможно, дало некоторые интересные модели, подобные STM, и HTM однажды может быть более полезным, чем сегодня.
Мое мнение: в рассуждениях о том, как упростить многопоточность, часто забывают, почему мы используем многопоточность. Часто предполагается, что, поскольку у нас есть несколько ядер, мы должны их использовать. Это все равно что сказать, что у нас есть ТБ дискового пространства, поэтому мы должны убедиться, что оно всегда заполнено. Причина многопоточности заключается в том, что это может улучшить производительность и, возможно, согласованность производительности. Если вы забыли об этом, то, скорее всего, вы получите решение, которое не только более сложное, чем однопоточное, но и более медленное.
Для меня большая честь, что Хроника была отмечена под знаменем «Причуды». 😉
Q: Самые востребованные и худшие идеи в JVM.
На мой взгляд: худшей особенностью был синхронизированный StringBuffer. Я писал об этом пару раз. Я бы добавил изменяемые объекты Date.
Лучшая особенность, которую я хотел бы видеть, — анализ побега, который действительно работал. Если у вас есть цикл for-each, который создает Iterator, который является локальной переменной полностью в домене Java, он сможет удалить объект. Он должен быть в состоянии удалить блокировку локальных переменных (которые живут и умирают в методе). Есть много общих, но тривиальных примеров, когда объекты не помещаются в стек.