Не совсем. Ни JEP-295 (jaotc) не упоминает jlink
, ни JEP-282 (jlink) не упоминает jaotc
.
Однако, поскольку jlink
просто создает урезанный JRE (но это все еще JRE!) С кодом вашего приложения, можно сказать, что он использует библиотеки AOT-ed, которые вы хотите.
Я решил следовать процедуре создания собственной библиотеки AOT для модуля java.base
, как описано в JEP-295, затем изменил сгенерированный jlink
модуль запуска на bin/my-app
, установив JLINK_VM_OPTIONS
следующим образом:
JLINK_VM_OPTIONS=-XX:AOTLibrary=./libjava.base-coop.so
Затем я запустил свой модуль запуска с time bin/my-app
, который делает HTTP-запрос к серверу на локальном хосте (чтобы избежать задержки в сети), а затем печатает полный HTTP-ответ.
Это занимает около 410 мс с AOT и 210 мс без него!
Для подтверждения правильности выбора AOT я добавил несколько диагностических флагов:
JLINK_VM_OPTIONS="-XX:+UnlockDiagnosticVMOptions -XX:AOTLibrary=./libjava.base-coop.so -XX:+UseAOTStrictLoading"
Он не показывал никаких ошибок или предупреждений, поэтому я считаю, что не совершил какую-то ошибку, которая могла бы исказить результаты.
В заключение, по крайней мере, в моем случае, смешивание jlink
и jaotc
, кажется, не оказывает положительного влияния, но обратите внимание, что в jaotc
JEP они действительно говорят, что:
AOT compilation of any JDK modules, classes, or of user code,
is experimental and not supported in JDK 9
Итак, я бы сказал, что слишком рано (на момент написания в мае 2018 г.) судить об этом ... давайте дадим им время для совершенствования этого механизма и надеемся, что они смогут добиться большего улучшения.
На данный момент более многообещающим способом ускорения ваших приложений может быть использование GraalVM и его команды native-image
.