JEP 243: Java-Level JVM Compiler Interface

Аннотация

Разработать интерфейс компилятора JVM на Java (JVMCI), благодаря которому JVM сможет использовать компилятор, написанный на Java, в качестве динамического компилятора.

Цели

• Дать возможность загружать во время выполнения Java-компонент, написанный с использованием JVMCI, и использовать его в брокере компиляции (compile broker) JVM.

• Дать возможность загружать во время выполнения Java-компонент, написанный с использованием JVMCI, чтобы доверенный Java-код мог с его помощью устанавливать в JVM машинный код, который можно вызвать через Java-ссылку на установленный код.

Что не является целью

• Интеграция динамического компилятора на основе JVMCI (например, Graal).

Критерии успеха

• Возможность запускать динамический компилятор на основе JVMCI на немодифицированной JVM. Производительность компилятора и генерируемого им кода не имеет большого значения, поскольку в JDK 9 JVMCI будет в статусе Experimental (экспериментальная функция) и, соответственно, будет включаться только указанием определённых флагов в командной строке.

Мотивация

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

Описание

API JVMCI будет состоять из механизмов для:

• доступа к структурам данных VM, которые нужны оптимизирующему компилятору байт-кода в машинный код, например к классам, полям, методам, данным профилирования и т. д.;
• установки скомпилированного кода вместе со всеми метаданными, которые нужны JVM для управления скомпилированным кодом, например картами GC и информацией для поддержки деоптимизации;
• подключения к системе компиляции JVM для обработки запросов JVM на создание машинного кода для методов.

Отличной демонстрацией того, как с помощью JVMCI написать и развернуть в JVM высокопроизводительный компилятор, служит Graal, пиковая производительность которого на широком спектре бенчмарков сопоставима с C2.

Альтернативы

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

Тестирование

Реализация JVMCI включает обширный набор модульных тестов для частей API, доступных разработчику компилятора, а также тестов методом белого ящика для внутренних частей, которые вызывают VM, чтобы реализовать публичные части.

Риски и допущения

Java API, позволяющий обращаться к внутренним механизмам VM, а также устанавливать и выполнять скомпилированный код, несёт очевидный риск для безопасности. В JDK 8 (где был создан первый прототип JVMCI и где он по-прежнему разрабатывается параллельно с портом на JDK 9) API JVMCI был скрыт от недоверенного кода: его загружал загрузчик классов, недоступный никакому коду, кроме кода из boot class path. В JDK 9 предполагается использовать средства контроля доступа, входящие в систему модулей (JEP 261), чтобы недоверенный код не мог использовать JVMCI. JVMCI должен быть защищён так же, как класс Unsafe.

В JDK 9 JVMCI будет в статусе Experimental, поэтому для его включения потребуются дополнительные параметры командной строки. Например:

-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=<name of compiler>

Статус Experimental позволяет активно экспериментировать с JVMCI и при этом снижает риски для пользователей JVM.

Зависимости

Как сказано выше, JVMCI зависит от средств контроля доступа из JEP 261, которые изолируют JVMCI от недоверенного кода.