Бертран Мейер - Основы объектно-ориентированного программирования

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

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

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

В ходе обсуждения выявлены две дополнительные проблемы эффективности работы сборщика мусора: производительность глобальная (overall performance) и в стартстопном режиме (incrementality).

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

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

collection_off

collection_on

collect_now

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

Более продвинутая техника, используемая в большинстве современных сборщиков мусора, известна как сборка мусора поколений (generation scavenging). Она исходит из следующего наблюдения: чем больше циклов сборки мусора объект пережил, тем больше вероятность, что он доживет до следующего цикла или всегда будет достижимым. Отсюда принцип работы сборщика мусора: "старые объекты оставляй нетронутыми". Сборщику полезна любая информация, позволяющая сканировать определенные категории объектов реже, чем остальные. Сборка мусора поколений обнаруживает объекты, существующие более чем определенное количество циклов. Такие объекты получают статус постоянной должности (tenuring)по аналогии с механизмом, защищающим экземпляры класса реальной жизни PROFESSOR , прошедших несколько циклов переизбрания и получивших, наконец, постоянную позицию. Объекты-долгожители будут рассматриваться отдельным сборщиком, работающим реже, чем сборщик "молодых" объектов.

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

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

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

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

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

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

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

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

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

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

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