Несерьезный подход (тривиальный)

Три ответа

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

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

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

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

[x]. Корневой объект системы.

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

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

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

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

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

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

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

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

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

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

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

Может ли быть оправдан несерьезный подход?

Несерьезный подход не создает проблем в системах, создающих небольшое число объектов, например, при проведении простых тестов и экспериментов.

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

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

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

Надо ли заботиться о памяти?

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

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

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

К несчастью, это не так.

Первая причина в том, что на практике виртуальная память не эквивалентна реальной. Если хранить большое количество объектов в виртуальной памяти, в которой меньшинство достижимых объектов рассыпано среди большинства недостижимых, то процесс выполнения будет постоянно вызывать перемещение страниц памяти, феномен, известный как пробуксовка (trashing), приводящий к драматическому увеличению времени выполнения. Действительно, системы виртуальной памяти усложняют эффективное разделение двух основных аспектов - пространства и времени. (См. "Эффективность", лекцию 1.)

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

Дата добавления: 2014-01-07