Документ обсуждает различные типы сборщиков мусора в Java, включая последовательный, параллельный, конкурентный, с гарантиями реального времени и garbage-first, каждый из которых имеет свои особенности и алгоритмы работы. Описываются механизмы памяти и управления поколениями объектов, а также методы учёта ссылок и оптимизации сборок. Так же рассматриваются стратегии остановки мира и особенности реализации сборщиков в различных средах и архитектурах.

1. Несколько реальных коллекторов
из Hotspot
• Последовательный коллектор
• Параллельный коллектор
• Конкурентный коллектор
• Коллектор с гарантиями
реального времени
• Garbage-first (G1)
10

2. Общие моменты
• Все коллекторы точные
• Несколько поколений:
 Молодое (YoungGen)
 Старое (OldGen)
 Перманентное (PermGen)
• Различные алгоритмы сборки в поколениях
 Копирующий в YoungGen
• Перенос объектов в поколение OldGen
• Выделение некоторых объектов прямо в OldGen
• Различные методы учѐта ссылок между поколениями
(барьеры)
• YoungGen поделѐн на TLABы
11

3. Барьеры чтения и записи
• Минимизация обходимого графа при малых
сборках
• Обход при малой сборке может не учитывать
ссылок в старшее поколение
• .. если сборщик может отслеживать ссылки
старшего в младшее
12

4. Барьеры чтения и записи
• Запись:
 При сохранение ссылки на объект в молодое
поколение в объекте из старого поколения
 При повышении (promotion) объекта в старое
поколение
• Чтение:
 На каждый доступ к объекту
 Позволяют исполнять действия при
использовании объекта (например
перемещение устаревшей ссылки)
• Подробнее:
http://cs.anu.edu.au/~Steve.Blackburn/pubs/pap
ers/wb-ismm-2004.pdf
13

5. Остановка мира (STW)
• Достаточно частая и нетривиальная операция
• Заморозить все потоки в консистентном
состоянии
• Продолжить исполнения из этого состояния
• Стратегии реализации:
 Кооперативная/синхронная
 Насильственная/асинхронная
• Возможные реализации (?)
• Реализация в HotSpot (взаимодействие с
JITом)
14

6. Сжатые указатели
• Использование 32-битных значений для
адресации на 64-битных платформах
• Уменьшает объѐм данных для передачи по
шине
• За счѐт дополнительных вычислений и
большей гранулярности
• Ptr = (Oop << Shift) + HeapBase
• Предполагает непрерывный (в виртуальных
адресах) хип
• Для x86:
obj.field := mov rax, [rbase+oop*Shift+fieldOffset]
15

7. Последовательный коллектор
• Относительно простой, надѐжный
• Достаточно производительный на небольших
хипах (~1G)
• Новое поколение:
 Копирующий коллектор
 Остановка мира (STW)
• Полная сборка
 Классический mark-sweep-compact
последовательный коллектор
 Остановка мира (STW)
• Преимущества, недостатки
16

8. Параллельный коллектор
• Ориентирован на многопроцессорные
серверные конфигурации,
высокопроизводительный
• В принципе, распараллеленная версия
предыдущего коллектора
• Алгоритмы:
 Потоки сборщика по числу логических
процессоров
 Разделение множества корневых объектов
между потоками
 Похищение работы для балансировки
17

9. Конкурентный коллектор
• Выполняется “почти” параллельно с исполнением
кода Java
• Мягкие гарантии на паузы
• STW чтобы пометить корневой набор
• STW для заключительной перемаркировки
• Не компактифицирует, выделяет и освобождает
используя freelist’ы
• Может исполняться всѐ время или периодически
• Фрагментация хипа, поэтому:
 Пытается объединять freelist’ы
 Сильная фрагментация – откат к сериальному
или параллельному коллектору
18

10. Коллектор с гарантиями
реального времени
• Жѐсткие гарантии реального времени для
некоторых потоков
• Алгоритм Хенриксонна,
http://www.cs.lth.se/home/Sven_Robertz/publ/L
CTES03-slides.pdf
• Сборка при выделении
• Преемптивный коллектор, плавающий
приоритет
19

11. Garbage-First (G1)
• Конкурентный и параллельный копирующий
коллектор с мягкими гарантиями на паузы
• Хип поделѐн на регионы
• У каждого региона – своя оценка стоимости сборки и
потенциального количества мусора
• Каждый регион знает все внешние ссылки на себя –
можно собирать произвольный набор регионов
• Вся работа поделена на части предсказуемого
размера
• Естественная локальность
• Предпочтение собирать регионы где много мусора
• Необходимо использовать достаточно дорогие
барьеры записи
20

12. Коллектор в Azul’s JVM
• Выполняется на специальном процессоре
(Vega) с аппаратной поддержкой барьеров
чтения/записи
• 3 фазы: mark, relocate, remap
• Полностью параллельный и конкурентный
• Без длинных STW
• Барьер на чтение может вести к
перемещению объекта из обработчика
• Подробнее
http://www.research.ibm.com/mre05/Click.pdf
21

13. Вопросы
1. Почему гипотеза поколений обычно
работает?
2. Какой бывает мусор (про какие объекты
проще или сложнее доказать их
недостижимость)?
3. Какого рода информация от системы
исполнения могла бы быть полезна
коллектору в процессе работы?
4. Попробуйте написать программу на Java
(например бинарное дерево) без явного
динамического выделения памяти.
22