Почему JVM-кеш JIT-скомпилированный код?

Question

Каноническая реализация JVM от Sun применяет некоторую довольно сложную оптимизацию для байт-кода для получения скоростей с близкого расстояния после того, как код был запущен несколько раз.

Вопрос в том, почему этот скомпилированный код не кэшируется на диск для использования при последующем использовании той же функции/класса?

Как бы то ни было, каждый раз, когда выполняется программа, компилятор JIT запускается заново, вместо использования предварительно скомпилированной версии кода. Не добавили бы эту функцию добавить значительный импульс к первоначальному времени выполнения программы, когда байт-код по сути интерпретируется?

Answer 1

Не прибегая к cut'n'paste ссылки, которую отправил @MYYN, я подозреваю, что это связано с тем, что оптимизация, которую выполняет JVM, не является статической, а скорее динамической, основанной на шаблонах данных, а также на шаблонах кода. Вероятно, эти шаблоны данных будут меняться в течение срока службы приложения, делая оптимизацию кэширования менее оптимальной.

Таким образом, вам понадобится механизм для определения того, были ли оптимальные оптимизированы сохраненные оптимизации, и в этот момент вы могли бы просто повторно оптимизировать «на лету».

Answer 2

Oracle's JVM действительно документален сделать это - цитирует Oracle,

компилятора может воспользоваться разрешением класса модели Oracle JVM для необязательно не проходят скомпилированную методы Java через вызовы база данных, сессий, или экземпляров. Такая постоянная позволяет избежать накладных расходов ненужных перекомпиляций через сеансов или экземпляров, когда это известно, что семантически код Java не изменился.

Я не знаю, почему все сложные версии VM не предлагают аналогичные варианты.

Answer 3

Я не знаю, фактические причины, не будучи каким-либо образом участвует в реализации виртуальной машины Java, но я могу думать о некоторых правдоподобных из них:

• Идея Java должна быть вписанный оновлено язык с произвольным доступом и размещение прекомпилированных материалов в файле класса является своего рода нарушением (только «вид», потому что, конечно, фактический байт-код все равно будет там)
• Это увеличило бы размеры файлов классов, потому что у вас было бы один и тот же код несколько раз, особенно если вы запускаете ту же программу в нескольких разных JVM (что не очень редко, когда вы рассматриваете разные версии как разные JV Ms, что вам действительно нужно делать)
• Файлы классов могут быть недоступны для записи (хотя это было бы довольно легко проверить)
• Оптимизации JVM частично основаны на информации о времени выполнения и на других запусках они могут быть не такими применимыми (хотя они все равно должны принести некоторую выгоду)

Но я действительно угадываю, и, как вы можете видеть, я действительно не думаю, что мои причины - настоящие шоу-пробки. Я полагаю, что Sun просто не считает эту поддержку приоритетной, и, возможно, моя первая причина близка к истине, так как это обычно может заставить людей думать, что файлы классов Java действительно нуждаются в отдельной версии для каждой виртуальной машины вместо того, чтобы быть кросс-платформенный.

Мой предпочтительный способ состоит в том, чтобы иметь отдельный переводчик байт-кода на родной язык, который вы могли бы использовать, чтобы сделать что-то вроде этого явно заранее, создавая файлы классов, которые явно созданы для конкретной виртуальной машины, возможно, исходный байт-код в чтобы вы могли работать с разными виртуальными машинами. Но это, вероятно, происходит из моего опыта: я в основном делаю Java ME, где очень больно, что компилятор Java не умнее компиляции.

Answer 4

Excelsior JET имеет кэширование JIT компилятор начиная с версии 2.0, который был выпущен еще в 2001 году Кроме того, его АОТ компилятор может скомпилировать кэш в единый DLL/общий объект, используя все оптимизации.

Answer 5

Обновленный к существующим ответам - Java 8 имеет JEP посвященного решению этого:

=>JEP 145: Cache Compiled Code. New link.

На очень высоком уровне, его заявленная целью является:

Сохранение и повторное использование скомпилированный машинный код из предыдущих серий, чтобы улучшить время запуска крупных Java-приложений.

Надеюсь, это поможет.