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

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

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

[x]. Объекты создаются по-разному. Массивы и строки имеют переменный размер; экземпляры других классов имеют фиксированный размер.

[x]. Наконец, как отмечалось, недостаточно освобождать память для повторного использования в самом ОО-приложении, - нужно возвращать ее навсегда операционной системе.

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

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

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

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

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

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

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

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

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

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

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