Управление памятью и сборщик мусора в .NET и Rotor 2.0 презентация

Доклад по теме «Управление памятью и сборщик мусора в .NET и Rotor 2.0»

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

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

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

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

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

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

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

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

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

Перемножение матриц не вызывает сбора мусора C# using System; /// <summary> /// Класс, представляющий матрицу /// </summary> 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; } } }

/// <summary> /// <summary> /// Пример перемножения матриц /// </summary> 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<size; i++) { for (int j=0; j<size; j++) { MatrixA [i,j]= (i + j) * 10; MatrixB [i,j]= (i + j) * 20; } } loopCounter = 1000; for (i=0; i < loopCounter; i++) Matmul(MatrixA, MatrixB, MatrixC); Console.WriteLine("Done."); Console.ReadLine(); } // Подпрограмма перемножения матриц public static void Matmul(Matrix A, Matrix B, Matrix C) { int i, j, k, size; double tmp; size = A.Rows; for (i=0; i<size; i++) { for (j=0; j<size; j++) { tmp = C[i,j]; for (k=0; k<size; k++) { tmp += A[i,k] * B[k,j]; } C[i,j] = tmp; } } } }

Здесь определен класс Matrix, в котором объявляется двухмерный массив для хранения данных матрицы. Метод Main создает три экземпляра этого класса с размерностью по 200×200 (каждый объект занимает примерно 313 Кб). Ссылка на каждую из этих матриц передается по значению методу Matmul (по значению передаются сами ссылки, а не реальные объекты), который затем перемножает матрицы A и B, а результат сохраняет в матрице C. Здесь определен класс 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)