Сборщики мусора поколений по своей природе дружественны кешу?


38

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

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


связанная мета-дискуссия о соответствующих тегах для вопроса.
Каве

Ответы:


19

Вот несколько статей, в которых говорится о последствиях использования сборщиков мусора для кэша:

Исходя из того, что я могу понять, основная проблема заключается в том, что системы сбора мусора обменивают пространство в памяти, чтобы избежать предварительного сбора. То же самое относится и к кеш-памяти. Как вы и предполагали, вещи в первом поколении, скорее всего, будут храниться в кеше, поэтому их распределение и сбор будут происходить намного быстрее, чем что-либо в основной памяти, или выгружаться на диск. Основной проблемой является размер первого поколения относительно размера вашего кэша. Если ваш кэш заполняется раньше, чем первое поколение, вы начинаете терять эти преимущества, так как промахи начинают накапливаться.


10

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

Коллектор поколений сосредоточится на том, что иногда называют «детским» пространством, но в конечном итоге / неизбежно придется собирать его на «старом» пространстве, вызывая полное сканирование памяти.

Это полное сканирование несовместимо практически со всеми схемами кэширования памяти и (особенно!) В том смысле, что почти все схемы кэширования / виртуализации памяти будут / должны плохо работать при любом повышении производительности в этом случае.

Таким образом, ключевым ответом на этот вопрос является то, как часто запускается полное сканирование, и насколько «плох» его эффект, когда это происходит, и можно ли это терпеть. это сводится к более зависимому от приложения свойству / вопросу.

Другими словами для «большинства» операций коллектора, кеш, вероятно, поможет ему (кеш и «молодое» пространство детской комнаты, как правило, будут перекрываться!), Но есть периодическая, прерывистая, возможная, неизбежная, тяжелая, может быть, даже «массивный» [деградирующий] всплеск производительности, когда пространство «старого поколения» заполнено полностью, а «частота попаданий» в кэш очень сильно ухудшится, так как многие объекты вне него все выбираются в узком цикле полным цикл сканирования / сбора. Другими словами, неизбежный периодический разрыв (где статистические оценки / средние показатели / тенденции производительности и т. Д. Вводят в заблуждение и неприменимы).

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

Посмотрите, например, сборщик мусора в кеше Zhou и Demsky.


Таким образом, вы могли бы утверждать, что GC поколений являются кеш-ориентированными по сравнению с классическими (не поколениями)?
Рафаэль

Я бы сказал, что GC должен быть спроектирован интегрированным образом с кешами и виртуальной памятью как частью его дизайна, что сложно в существующих архитектурах. однако, чтобы расширить ответ - да, сборщики поколений агрегируют / объединяют / группируют часто используемые объекты в непрерывную память, которая по своей природе будет более совместима с кешем, чем другие конструкции, в которых часто и редко используемые объекты разбросаны / смешаны (хотя последние все еще будет иметь некоторое преимущество кеша).
vzn

1
Один довольно сложный аспект объединения архитектур GC и кэширования / виртуализации заключается в том, что такие архитектуры обычно не заботятся о содержимом страниц памяти, но в системе GC они необходимы. Различные языки иногда обещают программистам разные функции, связанные с GC, и выяснить, какие функции поддерживать на уровне ОС, может быть сложно. Наилучшим подходом, вероятно, было бы сказать, что каждый объект должен содержать указатель на структуру, чьи начальные поля определяются ОС, но за которыми могут следовать специфичные для языка данные, которые ОС не будет знать или не заботиться.
суперкат
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.