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