На Хабре есть две статьи, автор которых пишет виртуальную машину для исполнения простого байткода, а потом применяет различные оптимизации для ускорения этой виртуальной машины. Кроме того, есть и компилятор простого С-подобного языка в этот самый байткод. Ознакмившись со статьями и этим компилятором, я подумал, что будет интересно изучить, как написать виртуальную машину этого языка, которая сможет делать JIT-компиляцию байткода с помощью библиотеки libjit. Опыт этого я и описываю в настоящей статье. В интернете есть статьи, описывающие испльзование этой библитеки, но все, что я видел, описывают генерацию машинного кода с помощью libjit для конкретных программ, а не произвольного байткода: есть официальный tutorial, серия статей и ещё серия сравнений на Хабре.  Весь мой код приведён в моём репозитории.  Как я уже упоминал, PigletC умеет компилировать простой С-подобный язык в байткод в текстовом представлении. Мне сперва понадобится программа, которая будет переводить байткод из текстового формата в бинарный.  Некоторые детали: Каждую инструкцию для простоты будем кодировать 4-мя байтами (тип int). Это не совсем оптимально, так как инструкций всего 25, но так будет проще, потому что я хочу, чтобы аргументы инструкций тоже были 4-ёх байтными. Теоритически, уменьшение размера исполняемого файла должно привести к уменьшению времени работы, но в нашем случае программы всё равно будут достаточно малы.  Таким образом, выходной бинарный файл представляет из себя последовательность int-ов, каждый из которых является либо кодом инструкции, либо аргументом инструкции, либо специальным значением (см дальше). Аргументы инструкций идут только после тех инструкций, которые имеют аргумент.  После инструкций перехода (JUMP, JUMP_IF_TRUE, JUMP_IF_FALSE) ставится индекс инструкции, на которую переход идёт - то есть порядковый номер числа, кодирующего эту инструкцию. Таким образом, ассемблер сначала проходит по байткоду, вставляя инструкции, но не ставя адреса перехода для инструкций перехода - они проставляются в конце, когда все адреса инструкций известны.  Для удобства, я решил что на месте каждой метки в бинарном файле будут записываться числа 0xcafe и 0xbabe. Таким образом, при анализе байткода будет сразу понятно, что сюда могут вести инструкции перехода. Вообще-то, это необязательно: можно было бы просто сохранить все аргументы инструкций перехода.  В остальном ничего особенно интересного в коде ассемблера нет. Приведён он здесь. Дальше напишем реализацию интерпретатора байт-кода, чтобы было с чем сравнивать исполнение JIT-компилированного кода.  Состояние виртуальной машины определяется следующими элементами: Стек. На стек можно класть 4-ёх байтных знаковые числа Память - лента 4-ёх байтных знаковых чисел, к которым можно обращаться по индексу.  Номер следующей инструкции для выполнения Изначально для реализации стека и памяти можно использовать STL контейнеры stack и vector, соответственно (можно и для обоих использовать вектор, а можно для обоих использвать дек) - тогда размеры памяти и стека не будут ограничены какими-либо константами. Однако, потом мне пришлось от этого отказаться, поскольку с JIT-компиляцией кусков кода это бы плохо сочеталось (вообще-то, в принципе в JIT компилированный код можно было бы запихнуть вызовы методов стека/вектора/дека, но я почти уверен, что заинлайнтить это было бы невозможно, а без инлайна это работало бы неэффективно).  В общем-то, реализация интерпретатора байт-кода довольно тривиальна: это огромный switch, в котором для каждой инструкции написано, что она делает.   Поскольку я пишу на С++, то буду использовать версию libjit для этого языка, с классами и наследованием.  Собственно, с помощью libjit вы сначала генерируете некоторое промежуточное представление кода вашей функции, а потом libjit превращает это представление в машинный код. Промежуточное предствление генерируется с помощью вызова функций libjit.  Для того, чтобы создать компилируемую функцию, надо создать класс, наследуемый от jit_function, определить конструктор и переопределить методы build и create_signature. Вообще-то, в PigletC программа (по крайней мере пока) может иметь только одну функцию, а байткод не имеет инструкций для вызова функции и возврата из неё (и поскольку инструкции перехода могут переходить только по адресам, известным на момент компиляции, то без дополнительной поддержки на уровне байткода никак не обойтись), но тем не менее функцию create_signature можно написать универсальную: Здесь считаем, что функция может применять только аргументы типа int, а возвращать либо int, либо void.  Теперь осталось всего ничего - собрать функцию на основе байткода. Тут у меня много времени ушло на размышления о том, что делать со стеком. При выполнении кода интерпретатором стек - это массив/вектор/стек, определённый в виртуальной машине. При JIT-компиляции же мне думалось, что будет эффективным чтобы как стек виртуальной машины использовался настоящий стек (то есть тот, на который под x86 указывает регистр %rsp). Однако, я не нашёл в libjit функций, которые позволили бы такое сделать: во-первых, видимо, библитека должна быть кроссплатформенной, а стек на разных архитектурах может быть разный, а во-вторых, libjit будет испльзовать стек как-то самостоятельно, и поэтому не может давать у нему прямой доступ. Здесь важно чётко понимать, какой код у нас выполняется в момент создания внутреннего представления, а какой - в момент работы JIT-компилированной функции. Например, в голову может прийти мысль для стека завести в функции build массив из значений типа jit_type_int и обращаться к нему. Но - индексы для этого массива неизвестны на момент компиляции.  Поэтому указатель на начало памяти, начало стека и указатель на размер стека будем передавать в конструктор JIT-компилированной функции и использовать в ней также, как и в интерпретаторе. Побочным эффектом этого будет то, что можно переключаться между исполнением функции в JIT-режиме и обычном - то есть если JIT-компиляция не поддерживает некоторые инструкции байткода, то она будет, встречая такую инструкцию, возвращать управление интерпретатору, который будет выполнять такую инструкцию и обратно переходить к JIT-компиляции (при этом придётся ещё и указатель на следующую инструкцию обновлять). Для начала предположим, что JIT-компиляция не будет поддерживать инструкции перехода.  Другим вариантом мог бы быть вызов malloc из JIT-функции и использование полученной памяти как стека.  Подготовка к компиляции функции будет выглядеть так: И где-то после этого кода: Все значения (константы) и переменные, которые JIT-компилированная функция может использовать, должны быть объявлены как переменные типа jit_value. Строчка за строчкой, мы делаем следующее: С помощью jit_type_create_pointer создаём тип "указатель на число". Первый аргумент jit_type_int - тип, на который указываем, число "1" - на сколько увеличивается счётчик количества использований типа. Наконец, тип передаём в new_value - и создаём в JIT - функции переменную типа "указатель на число" для хранения массива с памятью виртуальной машины Записываем в переменную для адреса памяти собственно адрес памяти проделываем пункт 1. для стека проделываем пункт 2. для стека проделываем пункт 1. для указателя на размер стека проделываем пункт 2. для указателя на размер стека Далее для удобства надо написать функции, которые будут "класть значения на стек" и "брать значения со стека". В кавычках потому, что в реальности они будут добавлять в промежуточное представление нашей функции инструкции, которые будут делать соответствующие операции.  Общий смысл такой: мы читаем значение по указателю на размер стека, записываем по этому указателю значение на 1 больше или меньше. Далее читаем (или пишем) по адресу на нужную ячейку стека значение.  Наконец, внутри функции сборки функции объвляем две вспомогательные лямбды, чтобы операции со стеком были короче.  Теперь обработка инструкции байткода пишется довольно просто. Вот несколько примеров: В третьей инструкции можно видеть, как вызвать нативную функцию, то есть скомпилированную в машинный код без участия libjit.  Здесь можно заметить, что код создания внутреннего представления libjit довольно таки похож на код интерпретатора виртуальной машины. Кажется, что при желании можно было бы сделать этот код полностью одинаковым (по крайней мере для большей части инструкций) - он бы только вызывал разные функции для операций со стеком и тп в зависимости от того, это jit компиляция или интерпретация, что позволило бы не делать двойную работу при добавлении новых инструкций.  Виртуальная машина (интерпретатор) теперь будет проверять, является ли следующая инструкция переходом. Если да, выполняет. Иначе вызывает JIT-компиляцию, которая компилирует функцию пока не встретит инструкцию, которую не поддерживает. Далее скомпилированную функцию будем сохранять в кеш и вызывать.  Естественно, пока это всё работает очень медленно - куски, которые мы компилируем, довольно небольшие, и интепретатору приходиться работать очень часто. Пока что это только демонстрация возможностей libjit.  Теперь надо добавить поддержку инструкций перехода. По сути, в libjit вы кроме переменных можете создавать метки, с которыми можно делать две операции: указывать, где в коде (то есть пока внутренним представлении libjit) эта метка должна стоять и объявлять переходы к этой метке.  Теперь при JIT-компиляции мы заведём словарь с отображением адресов инструкций на метки. Когда встречаем 0xcafe - ставим метку соответствующую на этом месте. Когда встречаем инструкцию перехода - указываем, что надо выполнить переход по метке, которую достаём из словаря по адресу перехода. Код: Запускаем виртуальную машину для исполнения некоторого простого кода, ожидая, что с JIT-компиляцией будет работать сильно быстрее - но оказывается, что работает даже немного медленнее: 1.2 секунды против 1.4 секунд.  В чём же дело? Проблема в том, что мы генерируем довольно сложный код, а оптимизатор libjit очень слаб - поэтому он особенно ничего с этим сделать не может.  Попробуем немного оптимизировать код, который мы генерируем, чтобы увидеть ускорение от JIT-компиляции.  Собственно реализация инструкций байткода у нас относительно простая. Очень хитро выглядят операции со стеком - мы ведь не просто инкрементируем или декрементируем переменную, хранящую размер стека (одна инструкция) - мы читаем её по какому-то адресу, затем пишем туда - и скорее всего libjit не может переместить её на регистр. Упростим это всё, сделав размер стека локальной переменной. При этом, совместную работу интепретатора и JIT-компиляции можно было бы сохранить, просто обновляя размер стека по переданному в компияцию адресу при возврате из функции.  Вот на этот раз ускорение значительное: интерпретация байткода работает за 1.2 секунды, а JIT-компилированный код работает за 0.4 секунды.  Хотя, с другой стороны, можно было бы ожидать и более существенного ускорения. Я предполагаю, что слабые оптимизации libjit в сочетании с тем, что байткод у нас от стековой, а не регистровой виртуальной машины, не позволяют коду действительно быть быстрым — ведь инструкции байткода постоянно используют стек, что сильно медленнее использования регистров. Отчасти эту проблему мы можем решить заменой некоторых последовательностей инструкций на более сложные инструкции, но в меньшем количестве. Эта оптимизация описывалась в статье про оптимизацию интерпретаторов байткода, на которую я ссылался в начале статьи.  В замерах производительности я тестировал байткод, получившийся из простейшей программы на PigletC: