Зачем JVM фиксирует изменения ссылок из старого поколения в молодое?
JVM фиксирует такие изменения, чтобы при сборке молодого поколения не сканировать всё старое поколение. Барьер записи отмечает область памяти или обновляет структуру межрегиональных ссылок, а сборщик затем проверяет только потенциальные ссылки из старых объектов в молодые.
Это снижает стоимость Young GC, но добавляет накладные расходы на операции записи и обслуживание служебных структур. Зафиксированная область может содержать ложные кандидаты: это ухудшает производительность, но не приводит к ошибочному освобождению живого объекта.
Поколенческая гипотеза утверждает, что большинство объектов живёт недолго, поэтому новые объекты выгодно собирать отдельно от долгоживущих. Такой подход появился как способ уменьшить объём памяти, который нужно просматривать при каждой сборке мусора.
Без дополнительной информации сборщик должен был бы искать ссылки на молодые объекты во всём старом поколении. Это сделало бы частые быстрые сборки молодого поколения зависимыми от размера всей старой части heap.
Рассмотрим старый объект, поле которого стало ссылаться на новый объект. Если при сборке молодого поколения сборщик проверит только корни и молодые объекты, он может не увидеть путь от старого объекта к молодому.
Пропуск такой ссылки опасен: живой молодой объект будет ошибочно признан недостижимым. Поэтому JVM должна регистрировать потенциально опасные записи, сохраняя корректность ценой дополнительной работы при изменении ссылок.
Перед или после записи ссылочного значения JVM выполняет барьер записи. В типичной реализации он помечает соответствующую карточку таблицы памяти как изменённую; такая карточка покрывает диапазон адресов, а не отдельную ссылку. Во время сборки этот диапазон сканируется, и найденные ссылки используются для поиска живых объектов молодого поколения.
Сборщик обычно не обязан точно знать, какая именно ссылка в помеченной карточке указывает в молодое поколение. Он может просканировать весь небольшой диапазон и получить лишние кандидаты. Это консервативный подход: лишняя проверка увеличивает стоимость GC, но не нарушает корректность.
В G1 память разделена на регионы, и для них поддерживаются remembered sets — сведения о регионах, из которых могут приходить ссылки в данный регион. Поэтому при сборке выбранных регионов G1 может обработать известные внешние источники ссылок, не просматривая весь heap.
Барьер записи не делает объект живым сам по себе и не предотвращает его сборку. Он лишь сохраняет информацию, необходимую сборщику для восстановления графа достижимости. Реализация барьера, точность служебных структур и момент их обработки зависят от конкретного сборщика и версии JVM.
Компромисс состоит в том, что частые записи ссылок увеличивают нагрузку на приложение, а большие объёмы грязных карточек или remembered sets удлиняют паузу либо фоновую работу GC. Полностью отказаться от барьеров нельзя без потери эффективности или корректности выбранного алгоритма.
Сервис обрабатывает большой поток сообщений. Долгоживущий кэш содержит структуры, в которые постоянно добавляются новые короткоживущие объекты. Young GC неожиданно тратит много времени, хотя сами молодые объекты невелики.
Рассматривались три варианта. Увеличение young-поколения уменьшало частоту сборок, но повышало объём работы каждой сборки. Полное сканирование старого поколения упрощало алгоритм, но делало паузы зависимыми от размера heap. Перестройка кэша на пакетную замену крупных структур уменьшала число межпоколенческих записей, но усложняла обновление данных.
Выбрали пакетную замену и ограничили частоту изменений долгоживущих структур. Профилирование подтвердило снижение числа грязных карточек и объёма remembered sets; паузы стали короче без простого увеличения heap. Решение было оправдано тем, что проблема находилась не в количестве живых объектов, а в высокой интенсивности межпоколенческих ссылок.
Нет. Барьер лишь формирует неполную, потенциально избыточную информацию о местах, где могут находиться ссылки. Сборщик всё равно должен обработать корни, молодые объекты и зарегистрированные области, а также учитывать особенности конкретного алгоритма и моменты, когда служебные данные очищаются или пересчитываются.
Ложное срабатывание означает, что сборщик проверит область, в которой на самом деле нет нужной межпоколенческой ссылки. Это увеличивает объём сканирования, но не меняет граф достижимости: объект считается живым только после проверки реальной ссылки или другого корректного пути от корня.
Опасными были бы ложные отрицания — ситуация, когда существующая ссылка не попала в отслеживаемую информацию. Поэтому реализации предпочитают консервативное накопление кандидатов, даже если часть из них лишняя.
Каждая запись может активировать барьер, пометить карточку памяти или изменить remembered set. При большом потоке обновлений это создаёт нагрузку на mutator-потоки, увеличивает объём служебных данных и заставляет сборщик просматривать больше потенциальных источников ссылок.
Число живых объектов влияет на копирование и обработку графа, но не описывает стоимость самих барьеров и последующего сканирования. Поэтому приложение может иметь небольшой объём живых данных, но заметные паузы из-за интенсивного изменения ссылочных полей.