Адаптивный размер кучи

Расширяя наш испытательный стенд для улучшения детектора проблем Plumbr GC , я написал небольшой тестовый пример, который, как мне показалось, может быть интересен для более широкой аудитории. Цель, которую я преследовал, состояла в том, чтобы проверить самоадаптивность JVM в отношении того, как сегментируется куча между eden, оставшимся в живых и постоянным пространством.

Сам тест генерирует объекты партиями. Пакеты создаются один раз в секунду, и каждый пакет имеет размер 500 КБ. На эти объекты ссылаются в течение пяти секунд, после чего ссылки удаляются, и объекты из этого конкретного пакета могут собираться мусором.

Тест был запущен с Oracle Hotspot 7 JVM в Mac OS X с использованием ParallelGC и ему предоставлено 30 МБ кучи для работы. Зная платформу, мы можем ожидать, что JVM запустится со следующей конфигурацией кучи:

• JVM будет начинаться с 10 МБ в Young и 20 МБ в пространстве Tenured, поскольку без явной настройки JVM использует соотношение 1: 2 для распределения кучи между пространствами Young и Tenured.
• В моей Mac OS X 10 МБ молодого пространства далее распределяется между Eden и двумя пространствами Выжившего, учитывая 8 МБ и 2×1 МБ соответственно. Опять же, это используемые по умолчанию платформы.

Действительно, когда мы запускаем тест и заглядываем под капот с помощью jstat , мы видим следующее, подтверждая наши оценки «за спиной»:

Отсюда мы также можем дать следующий набор прогнозов о том, что произойдет:

• 8 МБ в Eden будут заполнены примерно за 16 секунд — помните, мы генерируем 500 КБ объектов в секунду
• В каждый момент времени у нас есть приблизительно 2,5 МБ живых объектов — генерируя 500 КБ каждую секунду и сохраняя ссылки на объекты в течение пяти секунд, мы получаем примерно это число
• Незначительный сборщик мусора срабатывает всякий раз, когда Eden заполнен — ​​это означает, что мы должны видеть второстепенный сборщик данных каждые 16 секунд или около того
• После незначительного сборщика мусора мы закончим преждевременное повышение — места Survivor занимают всего 1 МБ, а живой набор объемом 2,5 МБ не поместится ни в одно из наших пространств 1 МБ Survivor. Таким образом, единственный способ очистить Eden — это распространение 1,5 МБ (2,5 МБ-1 МБ) живых объектов, не помещающихся в Survivor, в пространство Tenured.

Проверка журналов также дает нам уверенность в следующих прогнозах:

Не через 16 секунд, а, скорее, примерно через каждые 15 секунд, запускается сборка мусора, очищается Eden и распространяется ~ 1 МБ живых объектов в одно из пространств Survivor и переполняется остальное в старое пространство.

Все идет нормально. JVM ведет себя так, как мы ожидаем. Интересная часть начинается после того, как JVM некоторое время контролирует поведение GC и начинает понимать, что происходит. Во время нашего теста это происходит примерно за 90 секунд:

Здесь мы видим удивительную адаптивность JVM. Узнав о поведении приложения, JVM изменила размер оставшегося в живых пространства, чтобы быть достаточно большой, чтобы вместить все живые объекты. Новая конфигурация для пространства Юнга теперь:

• Eden 4MB
• Survivor пространства 3MB каждый

После этого частота ГХ увеличивается — Eden теперь на 50% меньше, и вместо ~ 16 секунд он заполняется примерно за 8 секунд или около того. Но выгода также видна, поскольку места для выживших теперь достаточно велики, чтобы в них можно было разместить живые объекты в любой момент времени. В сочетании с тем фактом, что никакие объекты не живут дольше, чем один минорный цикл ГХ (помните, что в любой момент времени всего 2,5 МБ живых объектов), мы прекращаем продвижение объектов в старое пространство.

Продолжая следить за JVM, мы видим, что старое использование пространства остается неизменным после принятия. Больше нет объектов, распространяемых на старые, но поскольку не запускается ни один крупный сборщик мусора, ~ 10 МБ мусора, который удалось распространить до того, как произошла адаптация, будет жить в старом пространстве вечно.

Вы также можете отказаться от «удивительной адаптивности», если уверены в том, что делаете. Указание -XX-UseAdaptiveSizingPolicy в параметрах JVM заставит JVM придерживаться параметров, заданных во время запуска, и не пытаться перехитрить вас. Используйте эту опцию с осторожностью, современные JVM, как правило, действительно способны предсказать подходящую конфигурацию для вас.