Исправление Java G1 ускорит JIT-компиляцию

Изменение сборщика мусора G1 в Java позволит снизить нагрузку на память и обработку данных и ускорить выполнение оптимизирующего JIT-компилятора C2 (just-in-time) Java, что благоприятно скажется на развертывании облачных вычислений, говорится в предложении сообщества Java.

Предложение OpenJDK упростит реализацию барьеров G1, которые записывают информацию об обращениях к памяти приложения, путем переноса их расширения с ранних этапов конвейера компиляции C2 JIT на более поздние, говорится в предложении.

В основе этого предложения лежит растущая популярность облачных развертываний Java, что привело к усилению внимания к снижению общих накладных расходов JVM. Среди целей плана - сократить время выполнения C2 при использовании коллектора G1, сделать барьеры G1 понятными для разработчиков HotSpot, не имеющих глубокого понимания C2, и гарантировать, что C2 сохраняет инварианты относительного упорядочивания обращений к памяти, точек безопасности и барьеров. Другой целью является сохранение качества кода, генерируемого C2, с точки зрения скорости и размера.

В предложении не ставится цель сохранить текущее раннее расширение барьеров G1 в качестве традиционного режима, говорится в предложении, и добавляется, что переход на позднее расширение барьеров должен быть полностью прозрачным, так что традиционный режим не нужен. Предложение было создано в середине декабря 2023 года и обновлено 9 апреля 2024 года.

Объясняя мотивы плана, авторы предложения ссылаются на растущую популярность облачных развертываний и значительные накладные расходы, которые несут оптимизирующие JIT-компиляторы, такие как C2. Предварительные эксперименты показывают, что раннее расширение барьеров G1 увеличивает накладные расходы C2 примерно на 10-20 % в зависимости от приложения. Снижение этих накладных расходов - ключевой момент для того, чтобы сделать платформу Java более подходящей для облачных вычислений, говорится в предложении.

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

Наконец, в предложении отмечается, что возможности C2 по оптимизации барьерного кода ограничены и что код аналогичного качества можно было бы генерировать, если бы детали реализации барьера были скрыты от C2 и раскрывались только в конце конвейера компиляции. Поэтому авторы предлагают расширять барьеры G1 как можно позже в конвейере компиляции C2.