JEP 278: Additional Tests for Humongous Objects in G1

Аннотация

Разработать дополнительные тесты методом белого ящика для механизма Humongous Objects сборщика мусора G1.

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

Мы не будем разрабатывать тесты для G1 Eager Reclamation.

Описание

Garbage First (G1) — сборщик мусора с поколениями, который делит кучу на регионы одинакового размера. У него есть фаза конкурентной сборки, которая может выполняться параллельно с приложением, и он многопоточный.

Объекты размером больше половины региона памяти, называемые humongous-объектами, G1 обрабатывает иначе, чем остальные объекты:

• Humongous-объекты всегда занимают некоторое число регионов. Если humongous-объект меньше одного региона, он занимает весь регион. Если humongous-объект больше N регионов и меньше (N+1) регионов, он занимает (N+1) регионов. Выделять память в свободном пространстве последнего региона, если оно есть, нельзя.

• Они могут быть собраны только в конце цикла конкурентной разметки, во время полной сборки мусора или при сборке молодого поколения в случае G1 Eager Reclaim

• Их никогда нельзя переместить из одного региона в другой.

Поскольку G1 — конкурентный и многопоточный сборщик мусора, тестировать его методом чёрного ящика очень сложно. Несколько способов собирать мёртвые объекты, несколько конкурентных потоков, возможность работать параллельно с запущенным приложением и в целом сложные алгоритмы делают почти невозможным понять внутреннее состояние G1. Чтобы решить эти проблемы, мы расширим WhiteBox API и реализуем тесты на Java, которые с помощью этого API проверяют внутреннее состояние G1. Новые методы WhiteBox API мы также сможем повторно использовать в нагрузочных тестах.

Чтобы проверить, что код, обрабатывающий humongous-объекты, работает как ожидается, нужно, чтобы G1 предоставлял больше сведений о внутреннем представлении humongous-объектов в куче. Мы добавим в G1 дополнительные отладочные методы, которые позволят получать информацию из его внутренних структур данных и управлять запуском сборки мусора. Последнее важно, потому что недостижимые humongous-объекты могут собираться по трём путям в коде: полная сборка мусора, конкурентная разметка и сборка молодого поколения в случае G1 Eager Reclamation. Чтобы протестировать каждый путь, нужно избежать остальных.

Для этого мы расширим WhiteBox API следующими методами:

• Методы для блокировки и запуска конкурентной разметки и полных сборок мусора.

• Методы для перебора регионов G1 и доступа к атрибутам регионов (например, свободен/занят/humongous).

• Методы для доступа к внутренним переменным G1, таким как объём свободной памяти, размер региона и количество свободных регионов.

• Методы для определения расположения регионов в куче, чтобы проверять, что в регионах, принадлежащих humongous-объектам, не происходит выделения памяти. (Это потенциально может стать первым шагом к API «heap walker», который позволит полностью обходить кучу Java).

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

Возможные альтернативы:

• Нативные тесты, встроенные в JVM. Такие тесты можно было бы запускать с помощью флага JVM. Они не подходят, поскольку сбой теста, скорее всего, приводил бы к аварийному завершению. JVM должна продолжать работать после проваленного теста, а при таком подходе это не гарантируется.

• Нативные тесты. Для этого потребовалось бы добавить отладочные методы в код G1 и, по сути, разработать нативный WhiteBox API. У такого подхода есть определённые недостатки: мы не смогли бы использовать эти отладочные методы в нагрузочных тестах. Но, что ещё важнее, нативного фреймворка для тестирования до сих пор нет.

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

Новые тесты могут потребовать изменений в G1. Это может повлиять на производительность и стабильность G1, хотя мы считаем это маловероятным. Если это негативно скажется на G1, мы сможем собирать бинарные файлы для product-сборки без отладочных методов.