2. Когда набор хранящихся в памяти активных объектов становится настолько большим, что возникает риск аварийного завершения выполнения приложения, если для размещения дополнительных объектов, которые в соответствии с алгоритмом должны создаваться в ходе нормального выполнения приложения, не найдется достаточно большого объема свободной памяти. В этом случае исполнительный механизм будет вынужден вытеснять из памяти и периодически перекомпилировать необходимый приложению код лишь для того, чтобы приложение было в состоянии продолжать дальнейшее выполнение. Если другой возможной альтернативой является только прекращение выполнения приложения из-за нехватки памяти, то единственным решением может быть лишь очистка памяти от JIT-компилированного кода, даже если это означает дополнительные затраты времени на последующую повторную компиляцию этого кода.
Краткий обзор методов управления памятью и сборки мусора
Полезно разобраться в том, каким образом исполнительный механизм взаимодействует с кодом и объектами приложения в процессе его выполнения.
Приведенные ниже схематические диаграммы помогут нам проследить, как осуществляется управление памятью на различных стадиях выполнения приложения.
Рис. 3.2. Упрощенное схематическое представление состояния памяти приложения в процессе выполнения
Таблица 3.1. Условные графические обозначения, используемые на рис. 3.2, 3.3 и остальных рисунках
Фигура Описание Темно-серые овалы Используемые в настоящее время объекты (например, объект Obj12 на рис. 3.2). Белые овалы Пассивные объекты. Эти объекты (например, объект Obj6 на рис. 3.2) являются "мусором", к которому у приложения больше нет доступа и от которого можно избавиться с целью высвобождения дополнительной памяти. Темно-серые прямоугольники Описания классов и типов, которые были загружены в память по той причине, что к типам осуществлял доступ выполняющийся код. Внутренние прямоугольники Код, содержащийся в классах. (Код целиком находится внутри класса.) Темно-серые внутренние прямоугольники Код, подвергнутый JIТ-компиляции, поскольку метод был вызван хотя бы один раз (например, код Code1 класса ClassXYZ на рис.3.2). Светло-серые внутренние прямоугольники Код, который еще не подвергался JIТ-компиляции. По сравнению с прямоугольниками JIТ-компилированного кода эти прямоугольники имеют меньшие размеры, ибо еще не скомпилированные методы (например, метод Code4 класса XYZ на рис. 3.2) занимают в памяти очень мало места.
Приведенную на рис. 3.2 схему можно прокомментировать следующим образом:
■ Размеры отдельных элементов схемы выбраны таким образом, чтобы они давали представление об относительных объемах используемой памяти. Визуально большие классы и типы используют больше памяти по сравнению с визуально меньшими, поскольку содержат больше "начинки". Объекты различных типов используют различные объемы памяти. Пассивные объекты занимают память до тех пор, пока не будет выполнена операция сборки мусора. Методы, не подвергавшиеся JIТ-компиляции, занимают в памяти очень мало места.
■ В память загружаются описания всех типов и классов, которые используются в вашем приложении. Для различных типов и классов требуются различные объемы памяти.
■ JIT-компиляции подвергаются методы класса, которые вызывались хотя бы один раз. Пример: JIT-компиляции подвергались коды Code1, Code2, Code3 и Code7 класса ClassXYZ.
■ Те методы классов, которые еще не вызывались, не компилируются и поэтому не занимают много места в памяти. Пример: методы Code4 и Code5 класса XYZ еще не подвергались JIТ-компиляции. Как только они будут вызваны, будет осуществлена их JIT-компиляция и произведено распределение памяти для откомпилированного кода.
■ Объекты представляют собой экземпляры типов и классов и требуют места в памяти.
■ "Активные (live) объекты" — это объекты, к которым ваш код может получить доступ путем непосредственного или опосредованного использования глобальных, статических и стековых переменных.
■ "Пассивные (dead) объекты" — это объекты, доступ к которым со стороны вашего приложения стал уже невозможным, но которые еще не были удалены из памяти исполнительным механизмом. Таковыми на рис. 3.2 являются объекты Obj 3, Obj 6, Obj 9 и Obj11. До тех пор пока эти объекты не будут удалены, они будут занимать память подобно активным объектам или JIT-компилированному коду.
По мере того как объекты и другие типы, для которых память распределяется из кучи, будут создаваться вашим приложением и впоследствии становиться ненужными, наступит такой момент, когда невозможно будет создать никакой другой дополнительный объект, не удалив из памяти пассивные объекты. Как только это произойдет, исполнительный механизм инициирует сборку мусора. Состояние памяти приложения непосредственно перед выполнением операции сборки мусора показано на рис. 3.3.
По окончании сборки мусора становится возможным уплотнение активных объектов в памяти. Удаление пассивных объектов из памяти с последующим уплотнением активных объектов во многих случаях позволяет сформировать непрерывные свободные участки памяти большого размера, которые могут быть использованы при создании новых объектов. Состояние памяти приложения непосредственно после выполнения операций сборки мусора и уплотнения объектов показано на рис. 3.4.
Рис. 3.3. Состояние памяти приложения непосредственно перед сборкой мусора
Рис. 3.4. Пассивные объекты удалены из памяти, а активные — уплотнены
В состоянии нормального устойчивого выполнения приложение периодически создает объекты и избавляется от них. В необходимых случаях исполнительный механизм осуществляет сборку мусора и уплотняет память, освобождая ее для размещения вновь создаваемых объектов. Типичное состояние памяти приложения в условиях сосуществования активных и пассивных объектов, а также JIT-компилированного и некомпилированного кода показано на рис. 3.5.
В случае нормально функционирующих приложений всегда имеется запас свободной памяти, достаточный для создания новых объектов и хранения ненужных, так что прибегать к сборке мусора приходится сравнительно редко. Объема областей памяти, освобождаемых в процессе сборки мусора, надолго хватает для того, чтобы приложение могло создавать новые объекты, не заботясь об удалении тех, необходимости в которых больше нет. Типичное состояние памяти приложения непосредственно после выполнения очередной операции сборки мусора представлено на рис. 3.6.
Иногда количество используемых активных объектов может возрастать настолько, что простое удаление пассивных объектов по типу "отслеживание и очистка" не может обеспечить освобождение достаточно большого объема памяти для того, чтобы исполнительный механизм мог создать и разместить в памяти новые объекты, которые требуются выполняющемуся коду приложения. В случае возникновения подобных ситуаций выполнение приложения должно быть прекращено из-за нехватки памяти. Состояние приложения, достигшего в ходе своего выполнения такого состояния, показано на рис. 3.7.
Рис. 3.5. Типичное состояние памяти приложения при его устойчивом выполнении
Рис. 3.6. Типичное состояние памяти приложения при его устойчивом выполнении непосредственно после сборки мусора
Рис. 3.7. Активные объекты, занимающие всю доступную память
.NET Compact Framework справляется с подобными ситуациями, освобождая большие количества памяти, занимаемой текущим JIT-компилированным кодом. Может быть сброшен любой код, не выполняющийся в данный момент с использованием стека (или стеков, если речь идет о многопоточном выполнении). Это позволяет востребовать обратно память и использовать ее для нужд приложения, связанных с необходимостью размещения новых объектов или JIT-компиляции нового кода в случае, если метод ранее не выполнялся, но теперь вызывается. Состояние памяти приложения после отбрасывания ранее JIT-компилированного кода и сборки мусора показано на рис. 3.8.
