JEP 365: ZGC on Windows (Experimental)

ZGC для Windows в статусе Experimental (экспериментальная функция)

Ответственный	Stefan Karlsson
Тип	Feature
Область	Implementation
Статус	Closed / Delivered
Выпуск	14
Компонент	hotspot / gc
Обсуждение	hotspot dash gc dash dev at openjdk dot java dot net
Трудоёмкость	S
Длительность	S
Зависит от	JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
Связан с	JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)
Рецензенты	Mikael Vidstedt, Per Liden
Одобрен	Mikael Vidstedt
Создан	2019/10/16 11:00
Обновлён	2021/08/28 00:16
Задача	8232364

Аннотация

Перенести сборщик мусора ZGC на Windows.

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

Мы не ставим целью поддержку Windows 10 и Windows Server версий старше 1803, поскольку в более старых версиях нет API, необходимого для резервирования памяти с помощью заполнителей (placeholders).

Описание

Бо́льшая часть кода ZGC не зависит от платформы и не требует изменений под Windows. Существующая поддержка барьеров загрузки (load barriers) для x64 не зависит от операционной системы и может использоваться и в Windows. Платформенно-зависимый код, который нужно перенести, связан с тем, как резервируется адресное пространство и как физическая память отображается в зарезервированное адресное пространство. API управления памятью в Windows отличается от POSIX API и в некоторых отношениях менее гибок.

Реализация ZGC для Windows требует следующей работы:

Поддержка многократного отображения памяти. ZGC использует цветные указатели (colored pointers), а для этого нужна поддержка многократного отображения кучи, чтобы к одной и той же физической памяти можно было обращаться из нескольких разных мест адресного пространства процесса. В Windows память, опирающаяся на файл подкачки, предоставляет физическую память с идентификатором (дескриптором), который не связан с виртуальным адресом, по которому она отображена. С помощью этого идентификатора ZGC может отображать одну и ту же физическую память в несколько мест.
Поддержка отображения памяти, опирающейся на файл подкачки, в зарезервированное адресное пространство. API управления памятью в Windows не так гибок, как mmap/munmap в POSIX, особенно когда нужно отобразить память, опирающуюся на файл, в ранее зарезервированную область адресного пространства. Для этого ZGC будет использовать принятую в Windows концепцию заполнителей адресного пространства. Концепция заполнителей появилась в версии 1803 Windows 10 и Windows Server. Поддержка ZGC для более старых версий Windows реализована не будет.
Поддержка отображения и снятия отображения произвольных частей кучи. Из-за устройства кучи ZGC в сочетании с динамическим выбором (и изменением) размера страниц кучи требуется поддержка отображения и снятия отображения произвольных гранул кучи. Это требование в сочетании с заполнителями адресного пространства Windows требует особого внимания, поскольку заполнители должны явно разделяться и объединяться самой программой, а не автоматически операционной системой (как в Linux).
Поддержка выделения (commit) и освобождения (uncommit) произвольных частей кучи. ZGC может динамически выделять и освобождать физическую память во время работы Java-программы. Для поддержки этих операций физическая память будет разделена на несколько сегментов файла подкачки, которые будут служить её основой. Каждый сегмент файла подкачки соответствует грануле кучи ZGC и может выделяться и освобождаться независимо от других сегментов.

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

Тесты, которые обычно выполняются для ZGC в Linux, будут выполняться и для Windows.

Зависимости

Предварительно необходимы следующие изменения в общем коде:

8232601: ZGC: параметризовать размер таблицы ZGranuleMap
8232602: ZGC: сделать ZGranuleMap независимым от ZAddress
8232604: ZGC: сделать отображение и снятие отображения в ZVerifyViews точными
8232648: ZGC: перенести ATTRIBUTE_ALIGNED в начало объявлений
8232649: ZGC: добавить обратные вызовы в ZMemoryManager
8232650: ZGC: добавить точки инициализации для платформенно-зависимого кода
8232651: добавить реализацию os::processor_id() для Windows