JEP 144: Reduce GC Latency for Large Heaps

Аннотация

Повысить производительность приложений, которым нужны большие кучи объёмом до 32 ГБ, за счёт сокращения задержек сборщика мусора.

Цели

Обеспечить на наборе подходящих бенчмарков работу с кучами объёмом 32 ГБ, в которых 60 % данных живые, при достаточно стабильном времени паузы 250–500 мс, заданном целевым временем паузы. Среднее время паузы может колебаться в пределах ±10 %.

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

Гарантии времени паузы не требуются. Улучшать характеристики GC для куч меньшего размера, которые уже хорошо обслуживаются существующими технологиями GC, не является ни целью, ни требованием.

Мотивация

Объём оперативной памяти (RAM) продолжает расти. Для нагрузок, которым нужно низкое и стабильное время паузы GC, JVM со сборщиком CMS может работать с кучами объёмом до 4–8 ГБ. У обычного недорогого сервера сейчас гораздо больше памяти, чем один экземпляр JVM может эффективно использовать для таких нагрузок, поэтому Java-приложения часто масштабируют горизонтально на несколько экземпляров JVM. Для многих приложений это может быть приемлемым решением, но вертикальное масштабирование фактически блокируется ограничениями GC в JVM. Среды без сборки мусора этим ограничениям не подвержены. Цель этого предложения — обеспечить низкое и стабильное время паузы при больших объёмах RAM, чтобы Java стала пригодной для тех существующих сценариев, где из-за ограничений GC приходилось проводить сложную переработку архитектуры или переходить на другие платформы.

Описание

Это будет сделано за счёт улучшения сборщика G1. Есть ряд CR, над которыми мы планируем работать для повышения производительности. Список ниже — наша отправная точка, а не окончательный список CR. Чтобы найти реальные узкие места и выбрать CR (и написать новые) для тех областей, где нужна дополнительная работа, требуются обширные измерения производительности.

• 6484965: G1: совместить фазу учёта живых объектов с разметкой

• 6868854: G1: устранить последовательные затраты Other в конце паузы GC

• 6949254: G1: ввести инфраструктуру для конкурентных операций в G1

• 6976060: G1: выделение памяти под humongous-объекты должно при необходимости запускать циклы разметки

• 7022456: G1: значительное увеличение потребления памяти по сравнению с другими сборщиками во время работы приложения

• 7052429: G1: избегать лишнего сканирования humongous-регионов во время конкурентной разметки

• 7068229: G1: динамически включать многопоточную обработку ссылок для пауз повторной разметки (remark)

• 7084525: G1: формировать записи журнала эргономических решений для выбора размера молодого поколения и для прогнозирования пауз

• 7098085: G1: частично молодые сборки (partially-young GC) в некоторых обстоятельствах не запускаются

• 7098512: G1: не очищать следующую битовую карту разметки в начале Full GC

Помимо этих ошибок и RFE, чтобы добиться постоянного времени паузы в диапазоне 250–500 мс, нужно полностью избежать полных сборок мусора (Full GC). Скорее всего, для этого потребуется новая схема, в которой вместо запуска полной сборки мы будем постепенно увеличивать объём выполняемой работы, если заметим, что не успеваем за скоростью выделения памяти или что фрагментация становится проблемой.