Есть ли сборщики мусора, которые учитывают подкачку?

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

При прочих равных, лучше сначала посетить объект, который уже выгружен в ОЗУ, прежде чем вставить другой блок в пейджинговый блок и, следовательно, выгрузить какой-либо объект.

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

Тем не менее, я не могу вспомнить ни одного сборщика мусора, который интегрируется с системой подкачки ОС, которая определяет порядок работы GC.

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

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

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

Подобные идеи естественны и, вероятно, описаны в некоторых статьях. Но я не припомню это от руки. Я думаю, что ранние статьи о Lisp GC содержат некоторые из этих идей (такие как: следует ли сначала следовать машине или cdr?).

Хорошая новость в этой роли копирования-сбора также заключается в том, что подкачка удобна для копирования, поскольку увеличивает доступное пространство для хранения. Напомним, что сборщик копий в принципе требует вдвое больше места, чем используется для реального хранения данных. Теперь эффект подкачки зависит также от адресного пространства машины и доступной физической памяти. На старых компьютерах физическая память была намного меньше доступного адресного пространства, поэтому подкачка была действительно космическим бонусом, позволяя использовать такие политики, как копирование GC. Даже если физическое пространство столь же велико, как и адресное пространство, можно захотеть поделиться им, чтобы у процесса, использующего GC, было меньше адресного пространства без подкачки страниц (см. Разбиение на страницы). Эти замечания несколько заменены использованием коллекционных поколений. Они обычно используют коллекцию копий для молодого поколения именно из-за этих качеств и потому, что молодое поколение в основном недолговечное.

Тогда у вас есть все взаимодействия поколений GC с системой кеша, которые обсуждались в предыдущем вопросе: сборщики мусора поколений по своей природе дружественны кешу?

Для получения дополнительной информации по этой проблеме, я бы поискал в Интернете, например, по ключевым словам сборка мусора и местность .

Эмери Бергер, Мэтью Херц и Йи Фенг поработали над этим.

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

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

Это видео разговора Эмери об этом, и он написал статью « Сборка мусора без подкачки страниц».

По некоторым причинам, кажется, не будет много работы над этим или какого-либо использования в «реальном мире». В конце статьи написано «Мы разрабатываем параллельный вариант алгоритма сбора закладок» , но я не могу отследить его.

CRAMM: поддержка виртуальной памяти для приложений, собираемых мусором, направлена на изменение ОС, чтобы GC создавал меньше страниц.

Использование резидентности страницы для балансирования компромиссов при отслеживании сбора мусора

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