λ
native image — это такая технология чтобы скомпилировать твой java код в native executable (или shared library) ahead-of-time. можно считать ее такой performance оптимизацией
Ух маркетолог
Size: a a a
2020 May 19
λ
АН
потому что интерпретаторам (для того чтобы использовать частичные вычисления, чтобы быстро работать (такой JIT для интерпретаторов граальвм)) нужно некоторые вещи от JIT компилятора хоста — то есть OpenJDK или GraalVM
Значит я могу запускать проекты использующие js интерпритатор graalvm, в рантайме OpenJDK, подключив jar библиотеки graalvm при запуске, но это будет работать медленнее чем в рантайме graalvm из-за того что последний имеет улучшенный JIT?
АН
native image — это такая технология чтобы скомпилировать твой java код в native executable (или shared library) ahead-of-time. можно считать ее такой performance оптимизацией
Знаю, но мне это не интересно. Как я понял, это позволяет быстрее запускать приложения, но лишает JIT оптимизаций
АН
А меня интересует серверное ПО
OS
да.
OS
graalvm тоже содержит рантайм OpenJDK
АН
Да, но модифицированный
OS
да, конечно.
АН
А существует ли какой-то патч JIT части, что бы я мог собрать чистый OpenJDK, но на нём бы так же эффективно работал код использующий graalvm? Конкретно меня интересуют js и python.
И кстати, могу ли я компилировать код использующий graalvm в окружении OpenJDK?
И кстати, могу ли я компилировать код использующий graalvm в окружении OpenJDK?
OS
конечно существует такой патч — это назвается graalvm
OS
да можешь компилироать код как угодно JIT начинается работать только после байткода
OS
как получать байткод - нет разницы, хоть руками генери
OS
типа как Scala например делает
OS
опять же, ты можешь взять JIT компилятор из graalvm
OS
и подсунуть его в свой openjdk как джар файл
OS
и если все версии и прочее совпадает - то будет работать быстро js
OS
если не совпадает — то конечно что-нибудь где-нибудь развалится
OS
гораздо проще и эффективнее — использовать сборки graalvm где это сделано за тебя
OS
но каждому свое конечно