Полная компиляция java-программы при её запуске

#java #jvm

Возможно ли заставить JVM (от Oracle) компилировать приложение не JIT (только ту
часть, которая была задействована), а полностью?
Возможно виртуальные машины других поставщиков могут это делать?
Возможно ли как-то влиять на оптимизацию кода (типа как в GCC -02, -03 и т.д.)?
P.S. Идея состоит в том, чтобы на взгляд пользователя приложение долго запускалось,
но, главное, никаких тормозов в ходе исполнения не ощущалось.    

Ответы

Ответ 1

Лично мое мнение что это пустая трата времени, но если вам так хочется, то есть специальные
продукты для Ahead Of Time компиляции Java приложений:

Excelsior JET 
RoboVM

Первый примечателен тем что разрабатывается уже давно (кстати русской командой раработчиков). 
Второй все еще в стадии alpha, но планируется обширная поддержка различных платформ
(Windows пока не всписке, зато есть Android и iOS).
Думаю если хорошо погуглить, то можно будет найти еще инструменты для AOT компиляции.


Ответ 2

Возможно ли заставить JVM (от Oracle) компилировать приложение не JIT (только ту
часть, >> которая была задействована), а полностью?
Да можно. воспользовашись AOT копилятором, но тут уже о VM речи не идет.
P.S. Идея состоит в том, чтобы на взгляд пользователя приложение долго запускалось,
но, >> главное, никаких тормозов в ходе исполнения не ощущалось.
Чтобы победить тормоза нужно понять откуда они идут. Самая частая проблема - нехватка
оперативной памяти, что она под собой несет:
когда у Вас появляется куча объектов которые пытается собрать GC, когда работает
GC то происходит стоп ворлд, когда замирает все приложение для VM это просто sw для
пользователя тормоз. можно попробовать прикрутить GC который это не делает, например
G1 или затюнить уже имеющийся. Попробовать использовать другую JVM, например JRockit
они позиционируют себя как реалтайм машина.


Я это все к чему, мне кажется, что если приложение тормозит, то тут вина не в том.
java транслирует байт код, в конце концов трансляция байт-кода, по сравнению с той-же
транзакцией к базе не самая ресурсоемкая операция. Ищите причину тормозов, а после
думайте как это оптимизировать.


Ответ 3

Можно попробовать запустить с опцией -server и/или настроить gc (например, включить
параллельный сборщик мусора -XX:-UseParallelGC).
По опыту могу сказать что тормоза обычно от сборщика мусора.


Ответ 4

Не думайте, что чем раньше JIT-компилировать, тем лучше. HotSpot Server JVM в режиме
интерпретатора не просто выполняет код, а ещё и статистику собирает, как он работает,
какие ветки выполняются чаще, какие реальные методы вызываются на виртуальных вызовах
и т. д. Потом код компилируется в машинный код, но не очень быстрый, который продолжает
собирать статистику. А уже потом эта информация используется для более эффективной
JIT-компиляции. В этом преимущество JIT-компиляции перед AOT-компиляцией: вы можете
произвести разный машинный код в зависимости от того, как приложение реально работает.
Это может его сделать быстрее. В некоторых экстремальных случаях сбор статистики позволяет
скомпилировать код так, что он будет в 10 раз быстрее, чем слепая JIT-компиляция.