JEP 364: ZGC on macOS (Experimental)

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

Ответственный	Erik Österlund
Тип	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/08/09 13:06
Обновлён	2021/08/28 00:16
Задача	8229358

Аннотация

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

Мотивация

Хотя мы ожидаем, что пользователи, которым нужна масштабируемость ZGC, будут работать в окружениях на базе Linux, разработчики нередко используют Mac для локальной разработки и тестирования перед развёртыванием приложений. Есть также пользователи, которые хотят запускать с ZGC настольные приложения, например IDE.

Описание

Реализация ZGC для macOS состоит из двух частей:

Поддержка многократного отображения памяти на macOS. Архитектура ZGC активно использует цветные указатели, поэтому на macOS нам нужен способ отображать несколько виртуальных адресов (соответствующих разным цветам в алгоритме) на одну и ту же физическую память. Для этого мы будем использовать API mach_vm_remap микроядра mach. Физическая память кучи хранится в отдельном адресном представлении, концептуально похожем на файловый дескриптор, но расположенном в (по большей части) непрерывном виртуальном адресном пространстве. Эта память повторно отображается в различные представления памяти ZGC, соответствующие разным цветам указателей в алгоритме.
Поддержка в ZGC несмежных резервирований памяти. На Linux мы резервируем 16 ТБ виртуального адресного пространства при инициализации. Чтобы это работало, мы предполагаем, что никакие разделяемые библиотеки не будут отображены в нужное адресное пространство. В конфигурации Linux по умолчанию такое допущение безопасно. Однако на macOS механизм ASLR вторгается в наше адресное пространство, поэтому ZGC должен допускать несмежное резервирование кучи. Общий код VM также должен перестать предполагать, что реализация GC использует одно непрерывное резервирование памяти. В результате такие API GC, как is_in_reserved(), reserved_region() и base(), будут удалены из CollectedHeap.

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

Мы опробовали альтернативный прототип на основе объектов разделяемой памяти POSIX. В нём для многократно отображаемой памяти использовался подход с файловым дескриптором. Мы отказались от этого подхода, потому что: а) он не поддерживал большие страницы и б) в реализации macOS функцию ftruncate можно вызвать только один раз, чтобы задать размер файла, из-за чего освобождать выделенную память (uncommit) было невозможно.

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

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

Зависимости

Чтобы подготовить почву для порта на macOS, необходимо избавить VM от допущения, что у GC одно несмежное резервирование памяти. Для удобства рецензирования эти изменения описаны в подготовительных улучшениях:

8229027: Улучшить то, как JNIHandleBlock::oops_do отличает oops от не-oops
8229278: Улучшить вывод местоположения в hs_err, чтобы он меньше полагался на внутреннее устройство GC
8229189: Улучшить трассировку в профилировщике утечек JFR для работы с несмежными кучами
8224815: Удалить использование CollectedHeap::is_in_reserved() вне GC
8224820: ZGC: поддержка несмежных резервирований кучи