OS
Какой аот? Native image? Все достижимые байткоды
Size: a a a
2018 October 06
OC
просто AOT
OS
Jaotc в опенджк?
OC
AOT compilation is done by a new tool, jaotc:
jaotc --output libHelloWorld.so HelloWorld.class
jaotc --output libjava.base.so --module java.base
It uses Graal as the code-generating backend.
jaotc --output libHelloWorld.so HelloWorld.class
jaotc --output libjava.base.so --module java.base
It uses Graal as the code-generating backend.
OS
Это вообще отдельная песня
OS
Это jaotc aot
OS
Оно там как-то использует Грааль компилятор мне кажется но я не вникал в детали
OC
оно точно использует, ибо это прописано в delivered джепе без обновлений)
OC
"The project will merge Graal core into the JDK, and deliver it in Linux/x64 builds."
https://bugs.openjdk.java.net/browse/JDK-8166089
https://bugs.openjdk.java.net/browse/JDK-8166089
OS
В общем, про что я хотел сказать давайте говорить длиннее но понятно
OC
Самое крутое будет, когда появится софт, который работает во всех трех режимах
OC
Джитится, аотится, и при желании компилируется в бинарник
e
и при этом динамический класс лоадинг
OC
скорей всего, динамический класслоадинг несовместим с идеей работы во всех возможных режимах. Это просто слишком сильное требование
OS
Динамический класслоадинг есть же: java -jar ...
OS
Как бы зачем аотить вещи чтобы потом подгружать нескомпилированный код и его там компилить потом в рантайме? Это если что не официальная позиция, это мой личный вопрос
OC
в случае когда такая ситуация довольно редкая, но иногда случается
OS
Ну так если случается java -jar ... И вперёд?
OC
это то же самое что в джит-компиляторе. Вот есть у тебя метод, который делает умные операции с объектами, но есть один специальный случай - null. Какие-нибудь методы работы с коллекциями. Вначале ты его оптимально скомпилировал житом и всё хорошо. А потом один раз на миллион входных данных туда прилетел null, и все, кэш кода запоганен