Управление памятью

Сборка мусора и внешние вызовы

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

Если ПО включает вызовы подпрограмм, написанных на других языках (называемых далее внешними программами), возможно, этим подпрограммам необходимо будет передавать ссылки на объекты. Это потенциально опасно для управления памятью. Предположим, что внешняя подпрограмма имеет следующий вид (преобразованная в соответствии с синтаксисом языка внешней программы):

r (x: SOME_TYPE) is
      do
         ...
         a := x
         ...
      end

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

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

adopt (a) - усыновлять
wean (a)   - отнимать от груди, отлучать

и должны быть частью интерфейса любой библиотеки, обеспечивающей взаимодействие ОО-программ и внешних программ. В следующем разделе описан подобный механизм для языка С. "Усыновление" объекта забирает его из области действия механизма утилизации; "отлучение" - возвращает возможность утилизации.

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

Среда с управлением памятью

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

Основы

Управление памятью - автоматическое. Среда включает сборку мусора, существующую по умолчанию. Вполне естественен вопрос пользователя "как включить сборщик мусора?". Ответ - он уже включен! В обычном использовании, в том числе и в интерактивных приложениях, он незаметен. Его можно отключить с помощью collection_off.

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

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

Сложные проблемы

Сборщик мусора сталкивается со следующими проблемами, вызванными практическими ограничениями на размещение объектов в современной ОО-среде:

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

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

Перемещение объектов

Необходимость возвращать память операционной системе порождает одну из самых утонченных частей механизма: сборщик мусора может при необходимости перемещать объекты.

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

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

Механизм сборки мусора

Приведем схему алгоритма, используемого сборщиком мусора.

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

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

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

Алгоритм сжатия памяти возвращает неиспользуемые участки памяти операционной системе, работая с наименьшими временными затратами. Он разбивает память на n блоков и за n-1 циклов сжимает их.

Повышенное чувство голода и потеря аппетита (Bulimia and anorexia)

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

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

Операции сборщика мусора

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

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

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

Можно настроить работу сборщика, задавая различные параметры, в частности, включение параметра speed заставит алгоритм не собирать всю доступную память с помощью механизма сжатия, а сразу использовать возможности операционной системы. Устанавливая другие параметры, можно включать механизмы: collection_off, collect_now и dispose из класса MEMORY.

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