Доклад по теме «Управление памятью и сборщик мусора в.NET и Rotor 2.0» студента 4 курса 443 группы Подходова Игоря Санкт-Петербург 2007

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

Для этого компилятор должен последовательно выполнить следующие задачи Для этого компилятор должен последовательно выполнить следующие задачи: выделить память под переменную; инициализировать выделенную память некоторым начальным значением; предоставить программисту возможность использования этой памяти; как только память перестает использоваться, необходимо ее освободить(возможно, предварительно очистив) наконец, необходимо обеспечить возможность последующего повторного использования освобожденной памяти

Необходимо различать уничтожение памяти (уничтожение объекта/уничтожение путей доступа) и утилизацию памяти (сборка мусора) Проблема отслеживания различных путей доступа к структуре (различные указатели на одно и то же место, передача параметром в процедуру и т.д.) => утилизация памяти обычно проблематична Проблемы управления памятью 1.«Висячие» ссылки 2.«Мусор»

Фазы управления памятью: Начальное распределение памяти – методы учета свободной памяти Утилизация памяти – Простая (перемещение указателя стека) – Сложная (сборка мусора) Уплотнение и повторное использование – память либо сразу пригодна к повторному использованию, либо должна быть уплотнена для создания больших блоков свободной памяти

Некоторые свойства сборки мусора: Реализация сборки мусора должна использовать как можно меньший объем рабочей памяти (т.к. сам факт вызова сборки мусора означает недостаток памяти) Одно из стандартных решений – использование алгоритма с обращением указателей Затраты на сборку мусора обратно пропорциональны объему высвобожденной памяти! Если сборка мусора освободила слишком мало памяти, то имеет смысл прекратить исполнение программы

Алгоритм выделения памяти в.NET Все ресурсы выделяются из управляемой кучи Стековый механизм выделения памяти Если для создания объекта не хватает памяти, то производится сборка мусора: – Производится маркировка активных элементов (список корневых объектов хранится в JIT-компиляторе и предоставляется сборщику мусора) – Активные элементы сдвигаются "вниз" путем копирования памяти – Так как все указатели могли измениться, сборщикмусора исправляет все ссылки

Управление кучей Куча - это блок памяти, части которого выделяются и освобождаются способом, не подчиняющимся какой-либо структуре Куча требуется в тех языках, где выделение и освобождение памяти требуется в произвольных местах программы Серьезные проблемы выделения, утилизации, уплотнения и повторного использования памяти Самая сложная часть управления кучей – это сборка мусора

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

Сборка мусора производится маркировка активных элементов; она начинается с так называемых корневых объектов, список которых хранится в JIT-компиляторе.NET и предоставляется сборщику мусора. По окончании маркировки все активные элементы сдвигаются к началу кучи путем простого копирования памяти. Так как эта операция компрометирует все указатели, сборщик мусора также исправляет все ссылки, используемые программой.Замечание: Реально алгоритм сборки мусора, используемый в.NET, существенно сложнее, так как включает в себя такие оптимизации как слабые ссылки, отдельную кучу для крупных объектов, сборку мусора в многопоточных приложениях и т.д.

Перемножение матриц не вызывает сбора мусора C# using System; /// /// Класс, представляющий матрицу /// class Matrix { double[,] matrix; int rows, columns; // Не вызывается до закрытия приложения ~Matrix() { Console.WriteLine("Finalize"); } public Matrix(int sizeA, int sizeB) { rows = sizeA; columns = sizeB; matrix = new double[sizeA, sizeB]; } // Индексатор для установки/получения элементов внутреннего массива public double this[int i, int j] { set { matrix[i,j] = value; } get { return matrix[i,j]; } } // Возвращает число строк в матрице public int Rows { get { return rows; } } // Возвращает число столбцов в матрице public int Columns { get { return rows; } }

/// /// Пример перемножения матриц /// class MatMulTest { [STAThread] static void Main(string[] args) { int i, size, loopCounter; Matrix MatrixA, MatrixB, MatrixC; size = 200; MatrixA = new Matrix(size,size); MatrixB = new Matrix(size,size); MatrixC = new Matrix(size,size); /* Инициализируем матрицы случайными значениями */ for (i=0; i

Здесь определен класс Matrix, в котором объявляется двухмерный массив для хранения данных матрицы. Метод Main создает три экземпляра этого класса с размерностью по 200×200 (каждый объект занимает примерно 313 Кб). Ссылка на каждую из этих матриц передается по значению методу Matmul (по значению передаются сами ссылки, а не реальные объекты), который затем перемножает матрицы A и B, а результат сохраняет в матрице C. Для большего интереса метод Matmul вызывается в цикле тысячу раз. Иными словами, эти объекты используются для выполнения тысячи «разных» перемножений матриц и ни разу не инициируются сборки мусора. Следить за числом операций сбора мусора можно при помощи счетчиков производительности памяти, предоставляемых CLR. Однако при вычислениях с использованием более крупных блоков памяти сбор мусора окажется совершенно неизбежен, как только будет запрошено большее пространство, чем есть в наличии. В таких ситуациях можно прибегнуть к альтернативе, например выделить критичные к быстродействию участки в неуправляемый код и вызывать их из управляемого C#-кода. Но P/Invoke или вызовы.NET interop сопряжены с некоторыми издержками периода выполнения, поэтому такой способ следует использовать в последнюю очередь или в том случае, когда гранулярность операций достаточно груба, чтобы оправдать затраты на вызов. Сбор мусора не должен мешать разработке высокопроизводительного кода для научных расчетов. Его задача исключить проблемы с управлением памятью, с которыми иначе вам пришлось бы иметь дело самостоятельно.

Благодаря Rotor(архив от Microsoft под длинным названием Shared Source Common Language Infrastructure (CLI) Implementation Beta (кодовое название) c shared source кодом.NET) для разработчиков появились возможности: посмотреть на реализации сборки мусора, JIT- компиляции, протоколов безопасности, организацию среды и систем виртуальных объектов. технологию локализации невизуальных компонент технологию сборки сложных проектов использование UnmanagedApi4MetaData более глубокоее понимание работы определенных функции в.NET (Reflection, Remouting, IL)

Литература: Д. Кнут "Искусство программирования", Вильямс, J. Richter "Garbage Collection: Automatic Memory Management in the Microsoft.NET Framework", Parts 1 & 2, MSDN Magazine, November 2000 / December 2000 Microsoft C# Language Specification, Microsoft Press, 2001