JEP 523: Make G1 the Default Garbage Collector in All Environments

Аннотация

Сделать сборщик мусора Garbage-First (G1) сборщиком по умолчанию во всех средах, а не только в серверных.

Цели

Если сборщик мусора не указан в командной строке:

• HotSpot JVM всегда будет выбирать G1.

• В сценариях, в которых JVM раньше выбирала сборщик Serial, показатели производительности (пропускная способность, задержка, объём занимаемой памяти и время запуска) не должны существенно ухудшиться.

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

Целью не является:

• Запретить будущие изменения сборщика мусора по умолчанию. Типичные профили приложений меняются, производительность сборщиков тоже развивается, поэтому выбор сборщика по умолчанию следует пересматривать.

• Вмешиваться в выбор пользователя: явно выбранный сборщик всегда будет иметь приоритет над выбором JVM.

• Объявлять устаревшим или удалять какой-либо из существующих сборщиков.

• Изменять функциональность или поведение G1.

Мотивация

HotSpot Java Virtual Machine (JVM) обеспечивает автоматическое динамическое управление памятью, то есть сборку мусора: она непрерывно находит и удаляет неиспользуемые объекты и освобождает память, чтобы приложение могло использовать её повторно. Так разработчики могут писать код, не беспокоясь об управлении памятью. Сборка мусора повышает продуктивность, поскольку устраняет многие классы ошибок в приложениях, связанных с управлением памятью.

У разных приложений разные требования к показателям производительности: пропускной способности, задержке, объёму занимаемой памяти и времени запуска. Поэтому в JVM есть несколько сборщиков мусора, и каждый из них ориентирован на своё сочетание этих показателей. Например, ZGC отдаёт приоритет задержке, а Parallel — пропускной способности, тогда как G1 спроектирован так, чтобы соблюдать баланс между задержкой и пропускной способностью. Если вы знаете, какой сборщик лучше всего подходит для вашего приложения, вы можете указать его при запуске JVM; в противном случае JVM выберет сборщик за вас.

Мы сделали G1 сборщиком по умолчанию для серверных сред в JDK 9 (JEP 248). Тогда тестирование показало, что в ограниченных средах с одним CPU или с физической памятью меньше 1792 МБ у Serial были существенные преимущества по пропускной способности и объёму занимаемой памяти. Поэтому мы изменили алгоритм выбора GC в JVM так, чтобы в таких средах выбирался Serial.

С тех пор мы улучшили сборщик G1 по всем показателям, и тестирование показывает, что теперь G1 конкурентоспособен с Serial при любых размерах кучи. Благодаря нашей недавней работе по сокращению синхронизации (JEP 522) максимальная пропускная способность G1 близка к пропускной способности Serial. Максимальные задержки G1 всегда были лучше, чем у Serial, поскольку G1 освобождает память в старом поколении с помощью инкрементных сборок мусора, а не полных сборок. Наконец, в последних выпусках мы сократили использование нативной памяти в G1 до уровня, сопоставимого с Serial.

Теперь производительности G1 достаточно, чтобы заменить Serial во всех ситуациях, в которых JVM раньше выбрала бы Serial. Пора перестать выбирать Serial по умолчанию в ограниченных средах. Кроме того, так будет проще понимать поведение JVM и рассуждать о нём.

Описание

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

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

Это изменение влияет на показатели производительности JVM только в ограниченных средах. Поэтому мы тщательно протестируем производительность G1 и сравним его с Serial на широком спектре рабочих нагрузок в таких средах. Существенных различий в производительности быть не должно.

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

Возможно, некоторые приложения в ограниченных средах по-прежнему будут лучше всего работать с Serial. В таких случаях вы по-прежнему можете выбрать Serial явно.