Оба они в значительной степени делают то же самое. Определите, что метод горячий и скомпилируйте его вместо интерпретации. С помощью OSR вы просто переходите к скомпилированной версии сразу после ее компиляции, в отличие от JIT, где скомпилированный код вызывается при вызове метода во второй раз.
Кроме этого, существуют ли другие отличия?
В общем, компиляция "точно в срок" относится к компиляции собственного кода во время выполнения и выполнению его вместо (или в дополнение к) интерпретации. Некоторые виртуальные машины, такие как Google V8, даже не имеют переводчика; они JIT компилируют каждую функцию, которая выполняется (с различной степенью оптимизации).
Замена стека (OSR) - это способ переключения между различными реализациями одной и той же функции. Например, вы можете использовать OSR для переключения с интерпретированного или неоптимизированного кода на JIT-код, как только он завершит компиляцию.
OSR полезен в ситуациях, когда вы идентифицируете функцию как "горячую" во время ее работы. Это может быть необязательно, потому что функция часто вызывается; его можно было бы назвать только один раз, но он проводит много времени в большом цикле, который может выиграть от оптимизации. Когда происходит OSR, виртуальная машина приостанавливается, а фрейм стека для целевой функции заменяется эквивалентным фреймом, который может иметь переменные в разных местах.
OSR также может возникать в другом направлении: от оптимизированного кода до неоптимизированного кода или интерпретируемого кода. Оптимизированный код может делать некоторые предположения о поведении программы во время выполнения, основанной на прошлых поведении. Например, вы можете преобразовать вызов виртуального или динамического метода в статический вызов, если вы только видели один тип объекта-получателя. Если позже выяснится, что эти допущения ошибочны, OSR можно использовать, чтобы вернуться к более консервативной реализации: оптимизированный стек стека преобразуется в неоптимизированный фрейм стека. Если VM поддерживает inlining, вы даже можете завершить преобразование оптимизированного фрейма стека в несколько неоптимизированных кадров стека.
Да, это в значительной степени. Компиляция "точно в срок" может повысить производительность за счет компиляции "горячих точек" (пятна байт-кода, которые известны/должны выполняться очень часто) байт-кода к собственным инструкциям. On-Stack Replacement дополняет возможности JIT, заменяя длинный запущенный интерпретируемый "горячий" байт-код на его скомпилированную версию, когда она становится доступной. Упомянутая статья замены на стопке показывает хороший пример, когда компиляция JIT не была бы очень полезной без OSR.
Люди уже упомянули, что такое JIT.
замена на стеке (OSR)
Когда JVM выполняет Java-метод, он проверяет сумму количества раз, когда метод был вызван, и количество раз, когда любые циклы в методе имеют ответвление и решает, подходит ли метод для компиляции, Если это так, метод ставится в очередь для компиляции. Этот вид компиляции не имеет официального имени, но часто называется стандартным сборник.
Но что, если метод имеет очень длинный цикл или тот, который никогда не выходит и не предоставляет все логика программы? В этом случае JVM необходимо скомпилировать цикл без ожидания для вызова метода. Поэтому каждый раз, когда цикл завершает выполнение, ветвление счетчик увеличивается и проверяется. Если счетчик ответвления превысил его индивидуальный порог, тогда цикл (а не весь метод) становится подходящим для сборник. Такая компиляция называется заменой на стеке (OSR), потому что даже если цикл компилируется, что не является достаточным: JVM должна иметь возможность начать выполнение скомпилированную версию цикла, пока цикл все еще запущен. Когда код цикла завершил компиляцию, JVM заменяет код (on-stack) и следующую итерацию цикл будет выполнять гораздо более быструю скомпилированную версию кода.