Динамическое распределение памяти

Динамическое распределение памяти

Файл : ROLLER.DOC

Список - конечная последовательность, состоящая из нуля или более атомов или Списков.

Рассмотрим Список L = (a: N, b, c: (d: N), e: L), N = (f: ( ), g: (h: L, j: N)) а соответствующей диаграммой для него будет

Существует много способов для представления Списочных структур в памяти машины. Обычно все они являются вариациями на одну и ту же основную тему, согласно которой для представления общих лесов деревьев используются бинарные деревья: одно поле, скажем RLINK, используется для указания на следующий элемент Списка, а другое поле DLINK можно использовать для указания на первый элемент под-Списка.

Тогда Список можно представить в виде:

Но эта простая идея не вполне пригодна для наиболее часто встречающихся приложений, включающих обработку Списков.

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

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

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

Но поскольку общие Списки могут расти и умирать во время работы программы совершенно непредвиденным образом, зачастую очень трудно сказать точно, когда тот или иной узел становиться ненужным. Следовательно, проблема обслуживания списка свободного пространства представляется значительно более трудной при работе со Списками.

Представим себе, что мы разрабатываем универсальную систему для обработки Списков, которая будет использоваться сотнями других программистов. Для обслуживания списка свободного пространства предлагается два основных метода: счетчики ссылоки сбор мусора. В методе счетчиков используется специальное поле в каждом узле, в котором учитывается, сколько стрелок указывает на этот узел. За таким счетчиком довольно легко следить во время работы программы, и всякий раз, когда счетчик сбрасывается в нуль, данный узел становится свободным. Метод сбора мусора использует в каждом узле специальное поле размером в один бит, которое называют "битом маркировки" или просто "маркером". В этом случае идея состоит в том, что почти все алгоритмы не возвращают узлы в список свободной памяти и программа беззаботно работает до тех пор, пока не исчерпается весь этот список; тогда алгоритм "сбора мусора", используя биты маркировки, возвращает в свободную память все узлы, которые в данный момент программе недоступны, после чего программа продолжает работать.

Ни один из этих методов нельзя считать вполне удовлетворительным. Принципиальный недостаток метода счетчиков состоит в том, что он не всегда возвращает в список свободной памяти те узлы, которые фактически являются свободными. Он хорошо работает с частично перекрывающимися списками. Кроме того метод счетчиков ссылок отнимает вполне ощутимое пространство в памяти (правда, иногда это пространство, так или иначе, остается свободным из-за размера машинного слова).

Кроме неприятной потери одного бита в каждом узле, трудность метода сбора мусора заключается в том, что он крайне медленно работает, когда загрузка памяти почти достигает предела; в таких случаях количество свободных ячеек, полученных с помощью процесса сбора, не окупает затраченных на это усилий. Те программы, которым не хватает памяти (а это происходит со многими не отлаженными программами!), часто впустую расходуют массу времени, многократно и почти бесплодно вызывая сборщик мусора непосредственно перед тем, как окончательно исчерпать память. Эту проблему можно частично решить, позволив программисту указывать число k, и если на этапе сбора мусора найдено не более k свободных узлов, то работа программы прекращается. Еще одна проблема связана с затруднениями, которые возникают иногда при определении, какие Списки на данном этапе не являются мусором; если программист пользуется какими-либо нестандартными приемами или хранит какую-либо указательную информацию в необычном