Основы объектно-ориентированного программирования полностью

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

Для получения полного решения проблемы работы в стартстопном режиме крайне привлекательно выделить сборщику мусора отдельный поток выполнения, конечно, при условии поддержки многозадачности операционной системой. Этот прием известен, как сборка мусора "на лету" (on-the fly) или параллельная.

Во время сборки мусора на лету выполнение ОО-системы использует два отдельных потока (часто соответствующих двум отдельным процессам операционной системы): приложение и сборщик. Только приложение выделяет память объектам с помощью инструкций создания; только сборщик освобождает память с помощью reclaim операций.

Сборщик будет работать непрерывно, повторяя фазу пометки и следом фазу чистки для обнаружения и удаления недостижимых объектов.

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

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

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

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

"Какой тип аппаратного обеспечения наиболее пригоден для объектной технологии?" -

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

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

Наиболее удобный подход - представить эти свойства в виде класса, который назовем MEMORY. Класс приложения, нуждающийся в свойствах, будет наследником MEMORY.

Среди компонентов класса MEMORY будут представлены рассмотренные ранее процедуры: collection_off, collection_on, collect_now.

Другой важной процедурой класса MEMORY является dispose (не путайте с тезкой Pascal, которая освобождает память). Она связана с важной практической проблемой, иногда называемой финалом или окончательным завершением (finalization). Если сборщик мусора утилизирует объект, связанный с внешними ресурсами, вы можете пожелать включить в его спецификацию некоторое дополнительное действие, такое как освобождение ресурсов, выполняемое параллельно с утилизацией. Типичный пример - класс FILE, экземпляр которого представляет файлы операционной системы. Желательно иметь возможность в случае утилизации недостижимого экземпляра класса FILE вызвать некоторую процедуру, закрывающую соответствующий физический файл.

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

При ручном управлении памятью проблем не возникает: достаточно включить вызов dispose до вызова reclaim. Деструктор класса в С++ включает в себя две операции dispose и reclaim. Однако при наличии сборщика мусора приложение напрямую не контролирует момент утилизации объекта, поэтому невозможно вставить dispose в нужное место.