some_routine is local

rb1, rb2: BOOK3 eb: expanded BOOK3 do

create rb1;create rb2 a := rb1

end

На следующем рисунке показаны объекты, создаваемые вызовом some_routine, и ссылки с

присоединенными объектами.

Рис. 9.9. Объекты, присоединенные к локальным сущностям

Когда вызов some_routine завершается, объект О, представляющий цель вызова, все еще доступен (иначе не было бы этого вызова). Поле а этого объекта О в результате вызова присоединено к объекту B1 класса BOOK3, созданного первой инструкцией создания нашей подпрограммы. Поэтому объект B1 остается достижимым по завершении вызова. Напротив, объекты B2 и EB, которые были присоединены к rb2 и eb во время вызова, теперь становятся недостижимыми: в соответствии с текстом процедуры невозможно, чтобы какой-либо другой объект "запомнил" В2 или ЕВ.

Проблема управления памятью в ОО-модели

Подводя итог предшествующего анализа, определим оригиналы и соответственно достижимые объекты:

Определение: начальные, достижимые и недостижимые объекты

В каждый момент времени выполнения системы множество оригиналов включает: * Корневой объект системы.

* Любой объект, присоединенный к локальной сущности, или формальному аргументу, выполняемой в данный момент подпрограммы (для функции включается локальная сущность

Result).

Любые объекты, прямо или косвенно зависящие от оригиналов, достижимы. Любые другие объекты недостижимы. Память, занятую недостижимыми объектами, можно восстановить, (например, выделить ее другим объектам) сохраняя корректность семантики выполнения программы.

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

Такое предсказание возможно в некоторых случаях для строго управляемых структур данных. Примером является библиотечный класс, задающий список, - LINKED_LIST, рассматриваемый позже, и связанный с ним класс LINKABLE, описывающий элементы этого списка. Экземпляр LINKABLE создается только с помощью специальных процедур класса LINKED_LIST и может становиться недостижимым только в результате выполнения процедуры remove, удаляющей элементы списка. Для подобных классов можно представить себе особенную процедуру управления памятью. (Такой подход будет изучен позднее в этой лекции.)

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

Три ответа

С недостижимыми объектами можно поступать тремя способами:

*Проигнорировать проблему и надеяться, что хватит памяти для размещения всех объектов: достижимых и недостижимых. Это можно назвать несерьезным (casual) подходом.

*Предложить разработчикам включать в каждое приложение алгоритм, ищущий недостижимые объекты, и дать им механизм освобождения соответствующей памяти. Такой подход называется восстановлением вручную(manual reclamation) .

*Включить в среду разработки (как часть исполняемой системы (runtime system)) механизм, автоматически определяющий и утилизирующий недостижимые объекты. Этот подход принято называть автоматической сборкой мусора (automatic garbage collection).

Остаток лекции посвящен этим подходам.