Что случилось с JEP 145 (более быстрый запуск jvm из-за повторного использования скомпилированного кода)?

В 2012 году был создан JEP 145, чтобы: кэшировать скомпилированный собственный код на java для более быстрого запуска jvm.

В то время было официально объявлено .
Однако JEP 145 больше не существует.

Что с этим случилось? Идея звучит великолепно.
Мне не удалось найти официального заявления, почему и когда этот проект был отменен.


java optimization performance jit openjdk
person MRalwasser    schedule 08.09.2016    source источник
comment
Вы должны спросить об этом у сообщества OpenJDK. Это немного не по теме Stack Overflow.   -  person Andreas    schedule 08.09.2016
comment
Идея звучит великолепно, но попытка реализовать ее могла доказать обратное. В конце концов, потенциальный выигрыш - это часть времени запуска вашего приложения, не связанная с вводом-выводом. Попробуйте измерить это, а затем подумайте, что вам нужно добавить время ввода-вывода для загрузки кэшированного кода. Не удивлюсь, если окажется, что это не стоит затраченных усилий. Может быть другая деталь, скомпилированный код, созданный для путей кода, которые приложение взяло после запуска, не помогает, если приложение не принимает их во время запуск.   -  person Holger    schedule 14.09.2016
comment
@Holger Некоторые (возможно, неправильные) контраргументы: Кешированный код может быть загружен целиком без каких-либо поисков. Возможно, можно будет запустить его выполнение до того, как загрузится байт-код. Скомпилированный код, созданный для разных путей кода, скорее всего, по-прежнему намного быстрее, чем интерпретируемый. Должна быть возможность создать код, оптимизированный для запуска. +++ Но может быть, ты прав. Тем не менее, я думаю, это могло бы сработать, но ограниченный выигрыш и типичное использование Java делают это не стоящим усилий.   -  person maaartinus    schedule 15.09.2016
comment
@maaartinus: возможность загрузки кода одним куском зависит от формата файла, а файлы jar действительно ужасны, но это уже было решено с помощью архива «общих данных класса» для кода JRE (что действительно ускоряет запуск) и, вероятно, будет решаться с помощью модулей Java 9 для произвольных библиотек. Если (скомпилированный) кодовый путь не используется, это не помогает, что он будет быстрее, чем (интерпретируемый) кодовый путь на самом деле. Эту проблему решило бы создание оптимизированного кода запуска, но это совершенно другая функция, чем просто выгрузка результатов JIT для использования в будущем.   -  person Holger    schedule 15.09.2016

Ответы (1)


arrow_upward
1
arrow_downward

Текст JEP по-прежнему доступен в исходном репозитории JEP:

http://hg.openjdk.java.net/jep/jeps/raw-file/c915dfb4117d/jep-145.md

Похоже, что нет документально подтвержденной причины для его отмены. Но теперь мы знаем, что AOT находится в разработке и решает многие из тех же проблем, возможно, в способ, который проще реализовать и поддерживать. Фактически, AOT JEP говорит:

Возможно, вместо этого можно было бы сохранить очень позднюю копию низкоуровневого IR, но это кажется не менее сложным.

Это определенно кажется объяснением того, почему 145 - не лучший вариант.

person omajid    schedule 28.10.2016