Как интерпретатор интерпретирует код?

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

Так как же JIT фигурирует здесь? Основная цель JIT-компилятора-оптимизация. Часто существуют различные способы перевода определенного байт-кода в целевой машинный код. Самый performance-идеальный перевод часто неочевидно, потому что это может зависеть от данных. Существуют также ограничения на то, насколько программа может анализировать алгоритм без его выполнения -проблема останова является хорошо известным таким ограничением, но не единственным. Таким образом, компилятор JIT пробует различные возможные переводы и измеряет, как быстро они выполняются с реальными данными, обрабатываемыми программой. Поэтому требуется несколько исполнений, пока JIT-компилятор не найдет идеальный перевод.

одним из важных шагов в Java является то, что компилятор сначала переводит .java код в .class файл, который содержит байт-код Java. Это полезно, Так как вы можете взять .class файлы и запустить их на любой машине, которая понимает это промежуточный язык, к тому времени переводя его на месте строка за строкой, или кусок за куском. Это одна из наиболее важных функций Java compiler + interpreter. Вы можете непосредственно скомпилировать исходный код Java для собственного двоичного кода, но это отрицает идею написания исходного кода один раз и возможность его запуска в любом месте. Это связано с тем, что скомпилированный собственный двоичный код будет работать только на той же архитектуре оборудования/ОС, для которой он был скомпилирован. Если вы хотите запустить его на другой архитектуре, вам придется перекомпилировать источник на этот. При компиляции байт-кода промежуточного уровня вам не нужно перетаскивать исходный код, а байт-код. Это другой вопрос, так как вам сейчас нужен JVM, который может интерпретировать и запускать байт-код. Таким образом, компиляция байт-кода промежуточного уровня, который затем запускается интерпретатором, является неотъемлемой частью процесса.

что касается фактического выполнения кода в реальном времени: да, JVM в конечном итоге интерпретирует/запускает некоторый двоичный код, который может быть или не быть идентичным скомпилированному коду. И в однострочном примере они могут казаться внешне одинаковыми. Но интерпретация обычно не предварительно компилирует все, а проходит через байт-код и переводится в двоичную строку за строкой или кусок за куском. В этом есть плюсы и минусы (по сравнению с изначально скомпилированным кодом, например, компиляторами C и C), и много ресурсов в интернете, чтобы читать дальше. Смотрите мой ответ здесь или этой или этой один.

упрощение, интерпретатор представляет собой бесконечный цикл с гигантским переключателем внутри. Он читает байтовый код Java (или некоторое внутреннее представление) и эмулирует процессор, выполняющий его. Таким образом, реальный процессор выполняет код интерпретатора, который эмулирует виртуальный процессор. Это мучительно медленно. Одна виртуальная инструкция добавление двух чисел требует трех вызовов функций и многих других операций. Для выполнения одной виртуальной инструкции требуется несколько реальных инструкций. Это также меньше памяти эффективной как у вас есть как реальный, так и эмулированный стек, регистры и указатели инструкций.

while(true) {
    Operation op = methodByteCode.get(instructionPointer);
    switch(op) {
        case ADD:
            stack.pushInt(stack.popInt() + stack.popInt())
            instructionPointer++;
            break;
        case STORE:
            memory.set(stack.popInt(), stack.popInt())
            instructionPointer++;
            break;
        ...

    }
}

когда какой-то метод интерпретируется несколько раз, запускается JIT-компилятор. Он будет читать все виртуальные инструкции и генерировать одну или несколько собственных инструкций, которые делают то же самое. Здесь я генерирую строку с текстовой сборкой, которая потребует дополнительной сборки для собственных двоичных преобразований.

for(Operation op : methodByteCode) {
    switch(op) {
        case ADD:
            compiledCode += "popi r1"
            compiledCode += "popi r2"
            compiledCode += "addi r1, r2, r3"
            compiledCode += "pushi r3"
            break;
        case STORE:
            compiledCode += "popi r1"
            compiledCode += "storei r1"
            break;
        ...

    }
}

после создания собственного кода JVM скопирует его где-нибудь, пометит этот регион в качестве исполняемого файла и поручить интерпретатору вызвать его вместо интерпретации байтового кода при следующем вызове этого метода. Одна виртуальная инструкция может по-прежнему принимать несколько собственных инструкций, но это будет почти так же быстро, как и компиляция в машинный код (например, в C или c++). Компиляция обычно намного медленнее, чем интерпретация, но должна выполняться только один раз и только для выбранных методов.