Цель: Изучение процедуры сборки мусора

Задачи:

1. Изучить алгоритм сборки мусора на основе поколений.

2. Дополнить глоссарий терминов терминологией по данной теме.

Содержание темы:

Для повышения его эффективности алгоритм сборки мусора могут применяться некоторые методы оптимизации. Например, объекты могут размещаться в “поколениях”, где отдельное поколение представляет отдельный цикл сборки мусора.

Рассмотрим алгоритм сборки мусора на основе поколений.

Поколения – это механизм сборщика мусора, единственное назначение которого – повышение скорости. Сборщик мусора с поколениями иногда называют эфемерным сборщикам мусора. Его работа основана на следующих допущениях:

чем младше объект, тем короче будет его время жизни; чем старше объект, тем длиннее будет его время жизни;

сбор мусора, в части кучи выполняется быстрее, чем во всей куче.

Сразу после инициализации в управляемой куче нет объектов. Новые объекты, которые создаются в куче, составляют поколение 0. Проще говоря, объекты поколения 0 – это только что созданные объекты, еще не исследованные сборщиком мусора. Объект, который не участвует в цикле сборки мусора, относится к поколению 0. После каждого цикла сборки мусора поколение каждого объекта возрастает на единицу. Таким образом, объекты каждого поколения компактно собираются вместе, а сами поколения располагаются в управляемой куче от самого высокого до самого низкого положения. Долгоживущие объекты, например те, которые существуют в течение всего жизненного цикла программы, будут перемещены в конец управляемой кучи и в основном будут располагаться именно там. В результате ссылки на эти объекты будут очень редко меняться. По мере оптимизации произвольности сборка мусора будет проводиться только для некоторых поколений. При этом используется предположение, что долгоживущие объекты (т.е. в более высоких поколениях), вероятно, будут существовать более длительное время и в ходе сборки мусора их нужно будет проверять так часто, как вновь созданные объекты.

Пример. На рис. 1 показано только что запущенное приложение, выделившее пять объектов (А- Е). Через некоторое время объекты С и Е становятся недостижимыми.

Рисунок 1 – Вид кучи сразу после инициализации: все объекты в ней относятся к поколению 0, сбора мусора еще не было

При инициализации CLR выбирает пороговый размер для поколения 0, например 256 кб (конкретный размер может изменяться). Итак, если в результате выделения нового объекта размер поколения 0 превысил пороговое значение, должен начаться сбор мусора. Допустим, объекты А-Е занимают 256 кб. При выделении объекта F должен начаться сбор мусора. Сборщик мусора определит, что объекты С и Е – это мусор, и переместит объект D вплотную к объекту В. Объекты, пережившие сбор мусора (А, В и D), называются поколением 1, они были изучены сборщиком мусора один раз. Теперь куча выглядит так (рис. 2);

Рисунок 2 – Вид кучи после сбора мусора: выжившие объекты из поколения 0 переходят в поколение 1, поколение 0 пусто

После сбора мусора в поколении 0 нет объектов. Как всегда, новые объекты становятся поколением 0.

Как всегда, новые объекты становятся поколением 0. На рисунке 3 показано, что приложение продолжает работать и выделяет объекты F-K. Также во время работы приложения объекты В, J и Н стали недостижимы, и занятая ими память должна быть однажды освобождена.

Рисунок 3 – В поколении 0 созданы новые объекты, в поколении I появился мусор

А теперь представим, что при попытке выделить объект L размер поколения 0 превысил пороговое значение 256 кб, и поэтому должен начаться сбор мусора.

При этом сборщик мусора должен решить, в каких поколениях следует его выполнять. При инициализации CLR выбирает пороговый размер поколения 0. Это еще не все, CLR также выбирает пороговый размер для поколения 1, который составляет, скажем, 2 Мб.

Начиная сбор мусора, сборщик определяет, сколько памяти занято поколением 1. Пока еще поколение 1 занимает намного меньше 2 Мб, поэтому сборщик проверяет только объекты

поколения 0. Вспомните первое допущение сборщика с поколениями: у новых объектов время жизни будет короче. Согласно ему в поколении 0 скорее всего окажется много мусора, поэтому сбор его в поколении 0 позволит освободить много памяти. При этом сборщик просто игнорирует объекты поколения 1, что ускоряет процесс.

Игнорируя объекты поколения 1, сборщик повышает свою скорость, это очевидно. Но он повышает ее еще больше, выборочно проверяя объекты в управляемой куче. Если корень или объект ссылается на объект PIS старшего поколения, сборщик игнорирует все внутренние ссылки старшего объекта, уменьшая время построения графа достижимых объектов. Конечно, возможна ситуация, когда старый объект ссылается на новый. Чтобы не пропустить такие «старые» объекты, сборщик использует внутренний механизм JIT-компилятора, устанавливающий флаг при изменении поля ссылок объекта. Он позволяет сборщику выяснить, какие из старых объектов (если они есть) были изменены после последнего сбора мусора. Следует изучать только старые объекты с измененными полями, чтобы выяснить, не ссылаются ли они на новые объекты из поколения 0.

Сборщик мусора с поколениями также предполагает, что объекты, прожившие достаточно долго, будут жить и дальше. Так что велика вероятность, что объекты поколения 1 останутся достижимыми из приложения и впредь. Поэтому, проверив объекты поколения 1, сборщик нашел бы мало мусора и не смог бы освободить много памяти. Следовательно, сбор мусора в поколении 1 скорее всего окажется пустой тратой времени. Если в поколении 1 появляется мусор, он просто остается там. Сейчас куча выглядит так (рис. 4):

 

Рисунок 4 – Вид кучи после второго сбора мусора: выжившие объекты из поколения 0 переходят в поколение 1 (увеличивая его размер), поколение 0 пусто

Как видите, все объекты из поколения 0, пережившие сбор мусора, перешли в поколение 1. Так как сборщик не проверяет поколение 1, память, занятая объектом В, не освобождается, даже если этот объект будет недостижим на момент сбора мусора. И в этот раз после сбора мусора поколение 0 опустело, в это поколение попадут новые объекты. Допустим, приложение работает дальше и выделяет объекты L-O. Во время работы приложение прекращает использование объектов G. L и М, что делает их все недостижимыми. Теперь куча принимает такой вид (рис. 5):

 

Рисунок 5 – В поколении 0 выделены новые объекты, количество мусора в поколении 1 увеличилось

Допустим, в результате выделения объекта Р размер поколения 0 вновь превысил пороговое значение, что вызвало запуск сбора мусора. Поскольку все объекты поколения 1 занимают в совокупности меньше 2 Мб памяти, сборщик вновь решает собрать мусор только в поколении 0, игнорируя недостижимые объекты с поколении 1 (В и G). После сбора куча выглядит так (рис. 5):

 

Рисунок. 5. Вид кучи после третьего сбора мусора; выжившие объекты из поколения 0 переходят в поколение 1 (еще больше увеличивая его размер! поколение 0 пусто

Как видите, размер поколения 1 продолжает медленно увеличиваться. Допустим, к настоящему моменту поколение 1 разрослось, и его объекты занимают больше 2 Мб памяти. Приложение продолжает работу (поскольку сбор мусора только что закончился) и начинает выделять объекты с Р до S, снова заполняя поколение 0 до порогового размера. Теперь куча выглядит так (рис. 6):

 

Рисунок 6 – В поколении 0 выделены новые объекты, количество мусора в поколении 1 увеличилось

Когда приложение пытается выделить объект Т, поколение 0 заполняется, и вновь должен начаться сбор мусора. Но на это раз сборщик видит, что размер памяти, занятой объектами поколения 1, достигает пороговой величины 2 Мб. Сбор мусора в поколении 0 был выполнен уже несколько раз, и весьма вероятно, что за это время некоторые объекты поколения 1 стали недостижимы (как в нашем примере). Поэтому сейчас сборщик мусора решает проверить все объекты поколений 1 и 0. Вот куча после сбора мусора в обоих поколениях (рис. 7):

 

Рисунок 7 – Вид кучи после четвертого сбора мусора: выжившие объекты из поколения 1 переходят в поколение 2, а из поколения 0 – в поколение 1, поколение О снова пусто

Как и до этого, все выжившие объекты поколения 0 перешли в поколение 1, а объекты поколения 1, пережившие сбор мусора, перешли в поколение 2. Как всегда, сразу после сбора мусора поколение 0 пусто, и новые объекты попадут туда. Объекты поколения 2 изучены сборщиком не менее двух раз. После этого сбор мусора может быть выполнен еще несколько раз, но сборщик вновь проверит объекты поколения 1 не раньше, чем их совокупный размер достигнет порогового значения. Обычно сбор мусора в поколении 0 успевает пройти до этого еще несколько раз.

Управляемая куча поддерживает только три поколения: О, 1 и 2, поколения 3 не существует. При инициализации CLR выбирает пороговый размер для всех трех поколений. Как я говорил, пороговый размер поколения 0 – около 256 кб, а для поколения 1 – 2 Мб. Пороговый размер поколения 2 равен примерно 10 Мб. Как всегда, пороговые значения подбирают так, чтобы повысить скорость. Чем больше порог, тем реже выполняется сбор мусора. И в этом случае исходные допущения того, что у новых объектов будет короткое время жизни, а старые скорее всего будут жить дольше, позволяют повысить быстродействие.

Сборщик мусора CLR является самонастраивающимся. Это значит, что он изучает работу приложения прежде, чем приступить к сбору мусора. Например, если приложение создает множество объектов и пользуется ими очень недолго, сбор мусора в поколении 0 освободит много памяти. В действительности даже вероятна ситуация, когда можно будет освободить память всех объектов поколения 0.

Если сборщик видит, что после сбора мусора в поколении 0 остается очень мало выживших объектов, он может снизить порог для поколения 0 с 256 до 12S Кб.

Это означает, что сбор мусора будет выполняться чаще, но потребует меньше работы сборщика, поэтому рабочий набор вашего процесса не будет разрастаться. Фактически, если все объекты поколения 0 станут мусором, не придется даже дефрагментировать память после сбора – достаточно будет вернуть NextObjPtr в начало поколения 0, и сбор мусора можно считать законченным. Вот как быстро можно освободить память!

С другой стороны, если после обработки поколения 0 сборщик мусора видит множество выживших объектов, это говорит о том, что удалось освободить мало памяти. В этом случае сборщик мусора поднимет порог для поколения 0 до 512 кб. Теперь сбор мусора будет выполняться реже, но каждый раз будет освобождать больше памяти.

Сборщик динамически модифицирует порог поколения 0 после каждого сбора мусора. Он также модифицирует порог для поколений 1 и 2 при помощи аналогичной эвристики. При сборе мусора в этих поколениях сборщик определяет, сколько памяти было освобождено и сколько выживших объектов осталось. В зависимости от полученных данных, он может увеличить или уменьшить пороги этих поколений, чтобы повысить производительность приложения.