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

Описанная вами архитектура ЦП, к сожалению, слишком ограничена, чтобы прояснить это на всех промежуточных этапах. Вместо этого я напишу псевдо-C и псевдо-x86-ассемблер, надеюсь, таким образом, чтобы он был понятен, не будучи хорошо знаком с C или x86.

Скомпилированный байт-код JVM может выглядеть примерно так:

ldc 0 # push first first constant (== 1)
ldc 1 # push the second constant (== 2)
iadd # pop two integers and push their sum
istore_0 # pop result and store in local variable

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

while (true) {
    switch(instructions[pc]) {
    case LDC:
        sp += 1; // make space for constant
        stack[sp] = constants[instructions[pc+1]];
        pc += 2; // two-byte instruction
    case IADD:
        stack[sp-1] += stack[sp]; // add to first operand
        sp -= 1; // pop other operand
        pc += 1; // one-byte instruction
    case ISTORE_0:
        locals[0] = stack[sp];
        sp -= 1; // pop
        pc += 1; // one-byte instruction
    // ... other cases ...
    }
}

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

Хотя фактическое добавление, вероятно, происходит в регистре, код, окружающий добавление, довольно сильно отличается от того, что испустил бы компилятор кода Java-to-machine. Вот отрывок из того, что компилятор C может превратить в (псевдо-x86):

.ldc:
incl %esi # increment the variable pc, first half of pc += 2;
movb %ecx, program(%esi) # load byte after instruction
movl %eax, constants(,%ebx,4) # load constant from pool
incl %edi # increment sp
movl %eax, stack(,%edi,4) # write constant onto stack
incl %esi # other half of pc += 2
jmp .EndOfSwitch

.addi
movl %eax, stack(,%edi,4) # load first operand
decl %edi # sp -= 1;
addl stack(,%edi,4), %eax # add
incl %esi # pc += 1;
jmp .EndOfSwitch

Вы можете видеть, что операнды для сложения берутся из памяти, а не жестко запрограммированы, хотя для целей программы Java они постоянны. Это потому, что для интерпретатора они непостоянны. Интерпретатор компилируется один раз, а затем должен уметь выполнять все виды программ без генерации специализированного кода.

Целью JIT-компилятора является именно это: создание специализированного кода. JIT может анализировать способы использования стека для передачи данных, фактические значения различных констант в программе и последовательность выполняемых вычислений, чтобы сгенерировать код, который более эффективно выполняет то же самое. В нашем примере программы он выделит локальную переменную 0 регистру, заменит доступ к таблице констант перемещением констант в регистры (movl %eax, $1) и перенаправит доступ из стека к нужным машинным регистрам. Игнорирование еще нескольких оптимизаций (распространение копий, сворачивание констант и устранение мертвого кода), которые обычно выполняются, может закончиться следующим кодом:

movl %ebx, $1 # ldc 0
movl %ecx, $2 # ldc 1
movl %eax, %ebx # (1/2) addi
addl %eax, %ecx # (2/2) addi
# no istore_0, local variable 0 == %eax, so we're done

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

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

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

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

В упрощенном виде интерпретатор представляет собой бесконечный цикл с гигантским переключателем внутри. Он читает байт-код 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 ++). Компиляция обычно намного медленнее, чем интерпретация, но должна выполняться только один раз и только для выбранных методов.