JIT против переводчиков

Ответ 1

Прежде всего:
С JVM, как интерпретатор и компилятор (в JVM компилятором, а не исходный код компилятора, как JAVAC) нативный код (так называемый машинный код языка для базового физического процессора, как x86) из байт-код.

Какая разница:
Разница заключается в том, как они генерируют собственный код, насколько оптимизировано и насколько дорого стоит оптимизация. Неофициально интерпретатор в значительной степени преобразует каждую инструкцию байтового кода в соответствующую нативную инструкцию, просматривая предопределенную JVM-инструкцию для сопоставления машинных команд (см. Ниже рис.). Интересно, что дальнейшее ускорение в исполнении может быть достигнуто, если мы возьмем раздел байтового кода и преобразуем его в машинный код - поскольку рассмотрение целого логического раздела часто предоставляет комнаты для оптимизации в отличие от преобразования (интерпретации) каждой строки в изоляции ( к машинной инструкции). Этот акт преобразования части байтового кода в (предположительно оптимизированную) машинную инструкцию называется компиляцией (в текущем контексте). Когда компиляция выполняется во время выполнения, компилятор называется компилятором JIT.

Соотношение и координация:
Поскольку Java-дизайнер пошел на переносимость (аппаратное обеспечение и ОС), они выбрали архитектуру интерпретатора (в отличие от компиляции, сборки и компоновки c). Однако для достижения большей скорости компилятор также может быть добавлен в JVM. Тем не менее, поскольку программа продолжает интерпретироваться (и выполняется в физическом ЦП), "горячие точки" обнаруживаются JVM и генерируются статистические данные. Следовательно, используя статистику интерпретатора, эти разделы становятся кандидатами на компиляцию (оптимизированный собственный код). Фактически это делается "на лету" (таким образом, JIT-компилятор), и скомпилированные машинные инструкции используются впоследствии (а не интерпретируются). Естественно, JVM также кэширует такие скомпилированные фрагменты кода.

Предупреждения:
Это в значительной степени основополагающие концепции. Если фактический исполнитель JVM, это немного по-другому, не удивляйтесь. Так может быть и для виртуальной машины на других языках.

Предупреждения:
Такие выражения, как "интерпретатор выполняет байтовый код в виртуальном процессоре", "интерпретатор выполняет байтовый код напрямую" и т.д., Являются правильными, если вы понимаете, что в конце есть набор машинных инструкций, которые должны выполняться на физическом оборудовании.

Некоторые хорошие ссылки:. Я еще не выполнял расширенный поиск.

• [paper] Инструкция Складывание на аппаратно-письменной основе Java Virtual Машина by Hitoshi Oi
• [book] Компьютерная организация и дизайн, 4-е изд., Д. А. Паттерсон. (см. рис. 2.23).
• [web-article] Оптимизация производительности JVM, часть 2: Компиляторы, Eva Andreasson (JavaWorld)

PS: Я использовал следующие термины interchangebly - "собственный код", "код машинного языка", "машинные инструкции" и т.д.

Ответ 2

• Интерпретатор: считывает ваш исходный код или некоторое промежуточное представление (байт-код) и выполняет его непосредственно.

• JIT-компилятор: читает ваш исходный код или, как правило, какое-то промежуточное представление (байт-код), компилирует его на лету и выполняет собственный код.

Ответ 3

Jit является посредником для переводчиков и компиляторов. Во время выполнения он преобразует байт-код в машинный код (JVM или Actual Machine?). В следующий раз он берет из кеша и запускает Am я правильно?

Да, вы.

Интерпретаторы будут напрямую запускать байт-код без преобразования его в машинный код. Правильно ли это?

Да, это так.

Как настоящий процессор на нашем ПК будет понимать инструкцию.?

В случае интерпретаторов виртуальная машина выполняет собственную процедуру JVM, соответствующую каждой команде в байтовом коде, чтобы обеспечить ожидаемое поведение. Но ваш код на самом деле не скомпилирован с собственным кодом, как с компиляторами Jit. JVM эмулирует ожидаемое поведение для каждой команды.

Ответ 4

A JIT Compiler переводит байтовый код в машинный код, а затем выполняет машинный код.

Интерпретаторы читают ваш язык высокого уровня (интерпретирует его) и выполняют то, что задает ваша программа. Интерпретаторы обычно не проходят через байтовый код и jit-компиляцию.

Но два мира тают, потому что многие интерпретаторы берут путь к внутренней байт-компиляции и jit-компиляции для лучшей скорости выполнения.

Ответ 5

Я уверен, что JIT превращает байт-код в машинный код для любой машины, на которой вы работаете, в нужном месте. Альтернативой этому является запуск байтового кода в виртуальной машине Java. Я не уверен, что это так же, как интерпретация кода, так как я больше знаком с этим термином, который используется для описания выполнения сценария (не скомпилированного) языка, такого как ruby ​​или perl.

Ответ 6

В первый раз, когда класс ссылается в JVM, JIT Execution Engine перекомпилирует файлы .class(первичные бинарные файлы), сгенерированные Java Compiler, содержащие JVM Instruction Set, в двоичные коды, содержащие набор инструкций систем HOST. JIT хранит и повторно использует перекомпилированные двоичные файлы из памяти в будущем, там, сокращая время интерпретации и преимущества от выполнения собственного кода.

И есть еще один аромат, который делает адаптивную оптимизацию, идентифицируя большую часть повторно используемой части приложения и применяя JIT только над ней, там, оптимизируя использование памяти.

С другой стороны, простой старый интерпретатор java интерпретирует одну инструкцию JVM из файла класса за раз и вызывает процедуру против него.

Найти сравнение деталей здесь