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

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

Основы

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

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

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

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

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

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

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

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

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

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

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