Почему JVM не кэширует скомпилированный код JIT?
Каноническая реализация JVM от Sun применяет некоторую довольно сложную оптимизацию к байт-коду для получения почти собственных скоростей выполнения после того, как код был выполнен несколько раз.
Вопрос, почему этот скомпилированный код не кэшируется к диску для использования во время последующего использования той же функции/класса?
В настоящий момент каждый раз, когда программа выполнена, JIT-компилятор умирает заново, вместо того, чтобы использовать предварительную скомпилированную версию кода. Не был бы, добавляя эту опцию добавить значительное повышение начального времени выполнения программы, когда байт-код по существу интерпретируется?
4 ответа
Не прибегая к вырезанию ссылки, которую разместил @MYYN, подозреваю, что это связано с тем, что оптимизации, которые выполняет JVM, не статические, а динамические, основанные на паттернах данных, а также на паттернах кода. Вполне вероятно, что эти паттерны данных будут изменяться в течение жизни приложения, делая кэшированные оптимизации менее оптимальными.
Так что вам нужен механизм для установления, являются ли сохраненные оптимизации все еще оптимальными, и в этот момент вы могли бы просто переоптимизировать их на лету.
.Я не знаю реальных причин, не будучи никоим образом вовлеченным в реализацию JVM, но могу придумать некоторые правдоподобные:
- Идея Java заключается в том, чтобы быть языком, где бы он ни работал, и размещение прекомпилированного материала в файле класса является своего рода нарушением этого (только "своего рода", потому что, конечно, реальный байтовый код все еще был бы там)
- Это увеличило бы размер файла класса, потому что у вас был бы один и тот же код там несколько раз, особенно, если вы случайно запустите одну и ту же программу под несколькими разными JVM (что на самом деле не редкость, когда вы считаете разные версии разными JVM, что вам действительно нужно сделать)
- Сами файлы классов могут быть не записаны (хотя это было бы довольно легко проверить)
- Оптимизации JVM частично основаны на информации о времени выполнения, а на других запусках они могут быть не так применимы (хотя они все же должны обеспечивать некоторую выгоду)
Но я действительно догадываюсь, и как вы можете видеть, я не думаю, что какая-либо из моих причин на самом деле является шоу-стоппером. Я полагаю, что Sun просто не рассматривает эту поддержку как приоритетную, и, возможно, моя первая причина близка к истине, так как это обычно может также заставить людей думать, что файлы класса Java действительно нуждаются в отдельной версии для каждой ВМ, вместо того, чтобы быть кроссплатформенными.
Мой предпочтительный способ на самом деле был бы иметь отдельный переводчик с байткода на собственный, который можно было бы использовать, чтобы сделать что-нибудь подобное явно заранее, создавая файлы классов, которые явно собраны для конкретной ВМ, с возможно оригинальным байткодом в них, так что вы могли бы запускаться и с разными ВМ тоже. Но это, вероятно, вытекает из моего опыта: В основном я занимался Java ME, где очень больно, что компилятор Java не умнее в компиляции.
.Oracle JVM действительно документирован для этого -- цитируя Oracle,
компилятор может воспользоваться преимуществами Модель разрешения класса Oracle JVM до по желанию можно сохранить скомпилированный Java методы через вызовы базы данных, сессии или случаи. Такой сайт настойчивость позволяет избежать накладных расходов ненужные перекомпиляции сессии или случаи, когда известно, что семантически код Java не изменилась.
Я не знаю, почему все сложные реализации ВМ не предлагают схожих вариантов.
Jet Excelsior Jet имеет CACHING JIT Compiler с версии 2.0, выпущенной еще в 2001 году. Кроме того, его компилятор AOT может перекомпилировать кеш в одну DLL / общий объект, используя все оптимизации.