JEP 284: New HotSpot Build System

Аннотация

Переписать систему сборки HotSpot на основе фреймворка build-infra.

Цели

Цель этого проекта — заменить текущую систему сборки новой, значительно упрощённой системой на основе фреймворка build-infra. А именно:

• Использовать возможности фреймворка build-infra, чтобы свести к минимуму дублирование кода.
• Упростить систему сборки HotSpot, чтобы её код было проще сопровождать и чтобы снизить порог для дальнейших улучшений.

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

Мы не ожидаем от этого изменения какого-либо заметного прироста производительности, поскольку текущая система сборки HotSpot уже довольно тщательно оптимизирована для хорошей производительности.

Мотивация

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

Отсутствие полной интеграции с build-infra также мешает дальнейшему улучшению процесса сборки в целом, которое, возможно, позволило бы ещё больше ускорить общий процесс сборки JDK.

Описание

В общих чертах сборка HotSpot по сути не отличается от сборки любого другого нативного компонента JDK. По существу, нам нужно вызвать функцию build-infra SetupNativeCompilation() для libjvm.so. На практике сборка HotSpot развивалась иначе, чем сборка нативных библиотек в репозитории JDK, поэтому требуется ряд доработок.

Несколько примеров технических различий:

• HotSpot использует предкомпилированные заголовки, и их нужно поддерживать.
• HotSpot использует собственный набор флагов компилятора, который отличается от флагов, используемых в остальном продукте.
• libjvm.so может собираться несколько раз для разных вариантов, например server и client.
• HotSpot использует несколько различных возможностей, которые можно включать и отключать, например C1 и JVMCI.
• По историческим причинам HotSpot использует другие названия платформ и компиляторов.

Помимо компиляции нативной библиотеки libjvm.so, нужно выполнить и другие действия до и после сборки, например:

• Создание инструментов сборки, таких как компилятор adlc.
• Создание gensrc с помощью adlc и инструментария JVMTI.
• Поддержка Dtrace требует как предварительной, так и последующей обработки.
• Нужно собирать дополнительные библиотеки, такие как libjsig.so.

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

Основной метод тестирования будет тем же, что и при переводе сборки JDK, то есть с помощью скрипта compare.sh. Продукт собирается дважды — один раз старой системой сборки и один раз новой, — после чего запускается скрипт сравнения, который укажет на все различия в результатах сборки.

Нативные артефакты сборки никогда не будут на 100% совпадать байт в байт, поскольку технические различия влияют даже на повторные сборки одной и той же системой сборки. Тем не менее все оставшиеся различия, на которые укажет скрипт сравнения, должны быть учтены и объяснены как допустимые. (Например, это могут быть различия в отладочных данных из-за разных выходных каталогов сборки.)

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