Как работает JIT и OSR в JVM
В процессе изучения работы JVM у меня возникла путаница и я хотел бы задать несколько вопросов, чтобы разложить всё по полочкам:
- Во время работы виртуальной машины когда происходит вызов метода, то JIT-компилятор компилирует байт-код в нативный код (машинный код). В некоторых статьях я встречал понятие "интерпретация байт-кода" и правильно ли я понимаю, что это одно и то же (JIT = interpreter)? Или интерпретация предполагает нечто иное?
- Когда метод был вызван много раз (я так понимаю больше чем значение CompileThreshold), то внутренний профайлер виртуальной машины начинает считать его горячим и результат работы JIT-компилятора (машинный код) кэшируется. Вопрос такой, здесь тот же самый машинный код что и для всех методов или горячий метод как-то оптимизируется и потом заново компилируется?
- Размер кэша скомпилированных методов регулируется ключом ReservedCodeCacheSize (который, вроде как, по умолчанию равен 32Мб). Где хранится данный кэш, в heap'e? Просто интересно до каких разумных пределов можно его увеличивать. Возможно есть какая-то пропорция между размером памяти всего приложения и размером кэша.
- Если в приложении есть метод, который вызывается пару раз или один раз (клинический случай с main(...)), но сам метод состоит из множества длинных и вложенных циклов, то здесь, как я понимаю происходит OSR-компиляция. При каких условиях происходит OSR? Можно ли это как-то регулировать (по-аналогии с CompileThreshold) или при старте JVM указать, что данный метод "горячий" и перед его вызовом надо сразу оптимизировать? По своей специфики OSR-компиляция != JIT-компиляции, но если произошла OSR-компиляций, будет ли данный метод откомпилирован JIT'ом, чтобы при повторном вызове метода выполнялся оптимизированный код?
- В заголовке поста я написал просто JVM, но по факту я подразумевал Oracle JVM. В других известных JVM (Azule, JRockit) все устроено аналогично или есть своя специфика?
