"g1 gc и Обзор сборки мусора в hotspot jvm" @ jug spb, 31-05-2012

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

G1GC: Garbage-First Garbage Collector

Владимир Иванов

Oracle Corporation

[email protected]


Содержание

• Основы сборки мусора

• Обзор GC в HotSpot JVM

• G1: обзор архитектуры

• Миграция на G1

• Мониторинг работы GC


GC == Сборка мусора

• Находит и освобождает место, занимаемое

ненужными объектами

– Объекты вне транзитивного замыкания, включающего roots

(стеки потоков, статические поля классов и т.д.)

• Автоматическая и безопасная

• Проще, если граф объектов “заморожен”

– Stop-the-world (STW) паузы

• Возможны различные подходы

– c дефрагментацией или без

– Алгоритмы: copying, mark-sweep, mark-compact, ...

– Аллокация: linear, free lists, ...


Сборка мусора: до

B

Heap

C

D

G

H

I E

K

M J

A

F

Runtime

Stack

L


Сборка мусора: после

B

Heap

C

D

G

H

I E

K

M J

A

F

Runtime

Stack

L


Сборка мусора с поколениями

• Слабая гипотеза о поколениях

– Большинство объектов временные

– Старые объекты редко ссылаются на молодые

• Молодые и старые объекты содержатся отдельно

– В пространствах, называемых “поколения” (generations)

– Возможны разные алгоритмы для молодого и старого

поколения

– Mолодое поколение можно собирать отдельно от старого


Сборка мусора с поколениями

Молодое поколение

Старшее поколение

Перемещение объекта

Создание объекта Необходимо

отслеживать ссылки


Структура молодого поколения


Молодое поколение: сборка мусора




• Понятие «производительности» для GC

• Различные подходы к сборке мусора






Производительность GC

• 3 характеристики

• Throughput

• Объем вычислительных ресурсов, затрачиваемых на GC

• Предсказуемость

• На какое время прерывается работа приложения

• Footprint

• Объем используемой памяти


Производительность GC Оптимизируйте по 2 из 3

Throughput

Footprint Latency


Производительность GC Выбор стратегии

Throughput

Footprint Latency =


Производительность GC Изменение размера «кучи»

Throughput

Footprint Latency




• Понятие «производительности» для GC

• Различные подходы к сборке мусора






Чем хорош Stop-The-World GC?

• Проще всего определять достижимость объектов

– Граф объектов «заморожен»

• Проще всего перемещать объекты в «куче»

– В процессе сборки, «куча» может находиться в некорректном

состоянии

• Но:

– Приложение останавливается на все время сборки

– зависит от размера «кучи» / объема живых объектов


Инкрементальная сборка

• Попытка уменьшить паузы, вызванные GC, за счет

– Большего количества коротких пауз

– Фоновая сборка

• Требуется синхронизировать работу GC с

приложением

– Барьеры на чтение/запись


Предсказуемость vs Throughput

• STW

– Продолжительные паузы

– … но никакой лишней нагрузки для потоков приложения

– Максимальный throughput

• Инкрементальная сборка

– Короткие паузы

– Лишняя нагруза в потоках приложения

– Минимальные паузы за счет снижения throughput

• “Über GC” не существует!


GC в Hotspot JVM Взгляд изнутри

PSOld PSParOld

DefNew ParNew

Tenured

GC Framework GC Interface

Young

Gen

Whole

Heap

Parallel /

Concurrent Serial Parallel

CMS

Serial Parallel

G1

Old

Gen

PScavenge


GC в Hotspot JVM Взгляд извне

• SerialGC

– последовательная сборка молодого и старого поколений

• ParallelGC

– максимальный throughput

– параллельная сборка молодого и старого поколений

• CMS

– предсказуемость

– по возможности, сборка мусора в фоновом режиме

• G1


– слабо подвержен фрагментации


SerialGC

• Молодое поколение: последовательный копирующий GC

• Старшее поколение: последовательный Mark-Sweep-Compact

– Аллокация: линейная

• -XX:+UseSerialGC


ParallelGC

• Молодое поколение: параллельный копирующий

• Старшее поколение: параллельный Mark-Compact

– Аллокация: линейная

• -XX:+UseParallelGC -XX:+UseParallelOldGC


CMS

• Молодое поколение: параллельный копирующий GC

• Старшее поколение: фоновый Mark-Sweep GC

– Аллокация: free-листы

– Компактификация только при FullGC

• -XX:+UseConcMarkSweepGC


Garbage-First GC (G1)

• Фоновый и параллельный

• Высокая предсказуемость работы

• Сборщик мусора с поколениями, но …

• «Куча» состоит из регионов

• Нет физического разделения между молодым и старым

поколением

• Принадлежность регионов определяется динамически

• Для каждого региона известно где находятся объекты,

ссылающиеся на него

• “Remembered Set”

• Позволяет собирать регионы независимо


G1: Структура «кучи»

• Разбита на регионы

• Фиксированного размера

• 1MB-32MB

Разбита на регионы

• Фиксированного размера

• 1MB-32MB



• Молодое поколение

• Набор регионов

• Eden

• Survivor

• Выбираются динамически

E

S

S

E

E

E

E

E

Молодое поколение


• Eden

• Survivor

• Выбирается динамически



• Старое поколение

– Набор регионов

– Выбираются динамически

S

S

E

E

E

E

E

E

Старое поколение


• Выбирается динамически



H

S

S

H

H

E

E

E

E

E

E

Большие объекты

• Не помещается в регион

• Называется “humongous”

• Хранится в наборе

смежных регионов


S


S

H

H

H Collection Set

• Регионы, в которых будет

происходить GC

• Все молодое поколение

• Некоторые регионы из

старшего поколения

• Фоновая маркировка

определяет наиболее

подходящие


S


S

H

H

H Типы сборок

• В молодом поколении

• Смешанные (mixed)

• FullGC


H

H

S


S

S H

Сборка

• Копирование объектов в

регионы, помеченные как

часть «To»-пространства

• Survivor-регионы

• Регионы из старшего

поколения



S

H

H

H

Освобождение памяти

• From-space больше чем To-

space (не обязательно!)

• Компактификация за счет

копирования


E

H

H

S


H

RS

RS

• RSet == Remembered Set

• Информация о

местонахождении ссылок на

объекты из региона

• Позволяет собирать регионы

независимо

• RSet поддерживается

• Из старого в молодое

поколение

• Между регионами в старом

поколении


Барьер на запись

• Код, исполняемый при изменении значения поля

объекта с указателем

• Специфичен для каждого GC

• Абсолютно прозрачен для приложения

• Исполняется интерпретатором / генерируется JIT-компилятором

• Пример (для обновления card table):

a.f = x;

a.f = x;

card_table[index_for(&a.f)] = DIRTY_VALUE;


G1: Барьеры на запись

• 2 типа

– Pre-barrier

• Сохраняет старое значение поля

• Поддерживается корректность фоновой маркировки

• SATB (Snapshot-At-The-Beginning)

– Post-barrier

• Поддержка актуальности RSet

• Результат сохраняется в буферы, локальные для

потока

– В процессе фоновой сборки происходит обработка


G1: Фоновая маркировка

• Периодически все живые объекты в куче

помечаются

• обновляет информацию о достижимости по регионам

• автоматически освобождает регионы без живых объектов

• разбивает циклические зависимости среди недостижимых

объектов

• Параллельная и фоновая

• Стартует автоматически по достижении пороговой

занятости «кучи»


G1: Как включить?

• -XX:+UseG1GC

• -Xms/-Xmx

• Задаваемые цели на длительность и частоту пауз

– -XX:MaxGCPauseMillis=<num>

– -XX:GCPauseIntervalMillis=<num>


GC в Hotspot JVM Взгляд извне

• SerialGC

– последовательная сборка молодого и старого поколений

• ParallelGC

– максимальный throughput

– параллельная сборка молодого и старого поколений

• CMS


– по возможности, сборка мусора в фоновом режиме

• G1


– слабо подвержен фрагментации


Производительность GC Оптимизируйте по 2 из 3

Throughput

Footprint Latency


G1 рекомендуется, если… … не обязательно все…

• Нужна хорошая производительность

• Продолжительность пауз (<0.5-1s)

• Минимальная настройка

• Размер «кучи» >5Gb

• Занятость «кучи» >50%

• Скорость создания объектов серьезно варьируется

• Фрагментация «кучи»


G1 НЕ рекомендуется, если

• Приложение уже работает надежно без серьезных

проблем с производительностью

“If it isn't broken, don't fix it!”

• Жесткие требования на паузы <100мс

• Требуется максимальный возможный throughput

• даже в ущерб latency


Как выбирать GC?

1. ParallelGC

2. G1 PROFIT!

3. CMS

Паузы не устраивают

Паузы все еще не устраивают

«Куча» <2Gb

Подходит? ДA!


Диагностический вывод GC

• Параметры VM

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps

-Xloggc:<file>

-XX:+PrintGCDateStamps

-XX:+PrintHeapAtGC

-XX:+PrintTenuringDistribution

• Минимальные накладные расходы

• Анализ диагностического вывода GC

• PrintGCStats

• GChisto

http://gchisto.dev.java.net/

http://gchisto.dev.java.net/


VisualVM / VisualGC


Q&A

"g1 gc и Обзор сборки мусора в hotspot jvm" @ jug spb, 31-05-2012

Technology