JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

Аннотация

Z Garbage Collector, также известный как ZGC, — это масштабируемый сборщик мусора с низкой задержкой.

Цели

• Время паузы сборки мусора не должно превышать 10 мс
• Работать с кучами размером от относительно небольших (несколько сотен мегабайт) до очень больших (много терабайт)
• Снижение пропускной способности приложения не более чем на 15 % по сравнению с G1
• Заложить основу для будущих возможностей и оптимизаций сборщика мусора, использующих цветные указатели и барьеры загрузки
• Изначально поддерживаемая платформа: Linux/x64

Мы твёрдо намерены достичь этих целей для большого набора актуальных рабочих нагрузок. В то же время мы хотим признать, что не считаем эти цели жёсткими требованиями для любой мыслимой рабочей нагрузки.

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

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

Мотивация

Сборка мусора — одно из главных достоинств Java. Однако когда паузы сборки мусора становятся слишком длинными, они начинают негативно влиять на время отклика приложений. Устранив паузы сборки мусора или радикально сократив их длительность, мы сделаем Java более привлекательной платформой для ещё более широкого круга приложений.

Кроме того, объём памяти, доступной в современных системах, продолжает расти. Пользователи и разработчики приложений ожидают, что JVM сможет эффективно использовать всю эту память, и без длительных пауз сборки мусора.

Описание

Если коротко, ZGC — это конкурентный уплотняющий сборщик с одним поколением, основанный на регионах и учитывающий NUMA. Фазы stop-the-world ограничены сканированием корней, поэтому время паузы сборки мусора не растёт с увеличением размера кучи или набора живых объектов.

Один из ключевых принципов (решений) в устройстве ZGC — использование барьеров загрузки в сочетании с цветными указателями на объекты (т. е. colored oops). Именно это позволяет ZGC выполнять конкурентные операции, например перемещение объектов, пока работают потоки Java-приложения. С точки зрения потока Java, загрузка ссылочного поля объекта Java проходит через барьер загрузки. Помимо адреса объекта, цветной указатель на объект содержит информацию, по которой барьер загрузки определяет, нужно ли выполнить какое-либо действие, прежде чем позволить потоку Java использовать этот указатель. Например, объект мог быть перемещён; в этом случае барьер загрузки обнаружит это и выполнит соответствующее действие.

Мы считаем, что по сравнению с альтернативными техниками схема с цветными указателями обладает рядом очень привлекательных свойств. В частности:

• Она позволяет освобождать и повторно использовать память во время фазы перемещения (уплотнения), ещё до того, как будут исправлены указатели, ссылающиеся на освобождённые (повторно используемые) регионы. Это помогает снизить общие накладные расходы на кучу. Это также означает, что не нужно реализовывать отдельный алгоритм mark-compact для полной сборки мусора.

• Она позволяет обойтись относительно небольшим количеством простых барьеров сборщика мусора. Это помогает снизить накладные расходы во время выполнения. Это также означает, что код барьеров сборщика мусора в нашем интерпретаторе и JIT-компиляторах проще реализовать, оптимизировать и сопровождать.

• Сейчас мы храним в цветных указателях информацию, относящуюся к маркировке и перемещению. Однако универсальность этой схемы позволяет хранить информацию любого типа (если она помещается в указатель) и позволять барьеру загрузки выполнять любые действия на основе этой информации. Мы считаем, что это заложит основу для многих будущих возможностей. Например, в среде с неоднородной памятью это можно использовать для отслеживания шаблонов доступа к куче, чтобы при принятии решений о перемещении сборщик мусора переносил редко используемые объекты в «холодное» хранилище.

Производительность

Регулярные измерения производительности проводились с помощью SPECjbb® 2015 [1]. Производительность выглядит хорошо как с точки зрения пропускной способности, так и с точки зрения задержки. Ниже приведены типичные результаты бенчмарка (в процентах, нормированные относительно max-jOPS для ZGC), сравнивающие ZGC и G1 в режиме composite с кучей размером 128G.

(Больше — лучше)

ZGC
       max-jOPS: 100%
  critical-jOPS: 76.1%

G1
       max-jOPS: 91.2%
  critical-jOPS: 54.7%

Ниже приведено типичное время паузы сборки мусора в том же бенчмарке. ZGC удаётся оставаться значительно ниже целевых 10 мс. Обратите внимание, что точные значения могут различаться (как в большую, так и в меньшую сторону, но не существенно) в зависимости от конкретной машины и используемой конфигурации.

(Меньше — лучше)

ZGC
                avg: 1.091ms (+/-0.215ms)
    95th percentile: 1.380ms
    99th percentile: 1.512ms
  99.9th percentile: 1.663ms
 99.99th percentile: 1.681ms
                max: 1.681ms

G1
                avg: 156.806ms (+/-71.126ms)
    95th percentile: 316.672ms
    99th percentile: 428.095ms
  99.9th percentile: 543.846ms
 99.99th percentile: 543.846ms
                max: 543.846ms

Эпизодические измерения производительности проводились также на различных других бенчмарках SPEC® и внутренних рабочих нагрузках. В целом ZGC удаётся удерживать время паузы в пределах единиц миллисекунд.

[1] SPECjbb® 2015 — зарегистрированная торговая марка Standard Performance Evaluation Corporation (spec.org). Фактические результаты не заявляются как соответствующие требованиям, поскольку SUT может не удовлетворять требованиям SPEC к общедоступности.

Ограничения

Первоначальная версия ZGC в статусе Experimental не будет поддерживать выгрузку классов. Параметры ClassUnloading и ClassUnloadingWithConcurrentMark будут отключены по умолчанию. Их включение ни на что не повлияет.

Кроме того, ZGC изначально не будет поддерживать JVMCI (т. е. Graal). Если включён параметр EnableJVMCI, будет выведено сообщение об ошибке.

Эти ограничения будут устранены на более позднем этапе проекта.

Сборка и запуск

По соглашению возможности JVM в статусе Experimental по умолчанию отключены системой сборки. Поэтому ZGC как Experimental-возможность не будет входить в сборку JDK, если её явно не включить при компиляции параметром configure --with-jvm-features=zgc.

(ZGC будет входить во все сборки JDK для Linux/x64, выпускаемые Oracle)

Experimental-возможности JVM также нужно явно разблокировать во время выполнения. Поэтому, чтобы включить и использовать ZGC, понадобятся следующие параметры JVM: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

Подробнее о настройке ZGC см. вики проекта ZGC.

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

• Очевидная альтернатива — добавить в G1 возможность конкурентного уплотнения. Эта альтернатива была подробно проработана в прототипах, но в итоге от неё отказались. Мы пришли к выводу, что невозможно втиснуть эту функциональность в кодовую базу, которая изначально для этого не предназначалась, и при этом сохранить стабильность G1 и другие его положительные свойства.

• Теоретически альтернативой было бы так или иначе улучшить CMS. Однако есть несколько причин, по которым построение сборщика с низкой задержкой на основе алгоритма CMS не является ни привлекательным, ни жизнеспособным вариантом. Среди них отсутствие поддержки уплотнения, неограниченная по времени фаза remark, сложная кодовая база, а также то, что CMS уже объявлен устаревшим (JEP 291).

• Проект Shenandoah исследует использование указателей Брукса (Brooks pointers) для выполнения конкурентных операций (JEP 189).

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

Большинство наших существующих функциональных и нагрузочных тестов не зависят от сборщика и могут использоваться повторно без изменений. Будут добавлены дополнительные тесты, нацеленные на свойства и функции, характерные для ZGC.

Зависимости

• JEP 304: Garbage Collector Interface
• JEP 312: Thread-Local Handshakes