Являются ли отношения между пространствами/поколениями константой Java Heap?

Я прочитал эту статью о настройке сборки мусора виртуальной машины, чтобы лучше понять java сборщик мусора. Каждое пространство имеет область виртуального пространства кучи, в которую оно может расти, когда необходимое пространство кучи приближается к максимальному размеру кучи. Это можно увидеть на этой картинке:
_{(источник: oracle.com)}

Вы можете установить соотношение между молодым поколением и старым (постоянным) поколением с помощью параметра NewRatio, а соотношение между пространством Эдема и пространством выживших - с помощью параметра SurvivorRatio.

Недавно был задан этот вопрос о выяснении коэффициентов по умолчанию для пространств кучи. В нем говорится, что вы должны использовать параметр PrintGCDetails и рассчитать коэффициенты вручную.

Мой вопрос: увеличивается ли размер разных пространств кучи на одно и то же соотношение, сохраняя, таким образом, соотношение, установленное между ними, при постоянном запуске в течение всего времени выполнения приложения? Например, если для Young Generation и Old/Tenured Generation значение NewRatio по умолчанию равно 3, а первоначальное зарезервированное пространство кучи составляет 100 МБ для Young, и 300 МБ для Old. Если для старого пространства нужно зарезервировать больше памяти, скажем, 300 МБ, то есть 600 МБ. Память, зарезервированная для Young Space, также удваивается до 200 МБ, сохраняя соотношение без изменений?

Ответ 1

Я думаю, что вы имеете в виду GC Ergonomics и Адаптивная политика размеров

функция Hotspost GC, которая автоматически адаптирует размеры для поколений во время выполнения на основе текущего поведения распределения запущенного приложения.
Эта функция включена по умолчанию и управляет/адаптирует размер поколений во время выполнения.
на самом деле некоторые параметров GC будут игнорироваться, если вы не отключите политику Adaptive Size, например. -XX:SurvivorRatio=.

Вы можете отключить адаптивную политику размера с помощью -XX:-UseAdaptiveSizePolicy. Как только вы отключите AdaptiveSizePolicy, GC будет уважать начальный размер поколений, как указано вашими параметрами запуска (например, -Xms, -Xmx, -XX:MaxNewSize=, -XX:NewSize=, -XX:SurvivorRatio=), и они останутся постоянными.

Дополнительную информацию о политике Adaptive Size можно найти в UseAdaptiveSizePolicy и других опциях jvm.

Ответ 2

Отношение PermGen к молодому поколению частично поддерживается JVM, но, если поддерживать соотношение, ответ Нет.

JVM7 стал достаточно продвинутым и сложным, когда мы не должны прогнозировать распределение поколений внутри кучи.

В каждом цикле GC, который запускается JVM, он также выполняет метрический анализ, чтобы узнать о текущих приложениях в памяти. - Если больше объектов переживает несколько циклов GC, то PermGen уменьшается, а часть пространства выделяется YoungGeneration. В основном No. of objects x number of GC cycles they skip играет критерий при динамической корректировке коэффициента генерации.

Надеюсь, это поможет, спасибо.

Ответ 3

Изменить: Я думаю, что у меня что-то не так. Поместите эту заметку здесь, пока я исследую, чтобы не отправлять людей по неправильному пути!

Ответ Ales0x велик, если вы используете Parallel Scavenge GC (-XX:+UseParallelGC), но Concurrent Mark-Sweep GC (-XX:+UseConcMarkSweepGC) не поддерживает адаптивный размер.

С помощью Concurrent Mark-Sweep размер нового/молодого поколения устанавливается на основе начального размера кучи (если вы не укажете -XX:NewSize=). Размер нового поколения не изменится по мере роста кучи.