Типичный сборщик мусора поколений хранит недавно выделенные данные в отдельной области памяти. В типичных программах многие данные недолговечны, поэтому частый сбор молодого мусора (небольшой цикл GC) и нечастый сбор старого мусора - хороший компромисс между затратами памяти и временем, затрачиваемым на сборку мусора.
Интуитивно понятно, что преимущество сборщика мусора поколений по сравнению с сборщиком из одного региона должно увеличиваться по мере того, как увеличивается коэффициент задержки основной памяти по отношению к кэшу, поскольку к данным в молодом регионе часто обращаются и хранят все в одном месте. Подтверждают ли экспериментальные результаты эту интуицию?
programming-languages
computer-architecture
cpu-cache
garbage-collection
Жиль "ТАК - прекрати быть злым"
источник
источник
Ответы:
Вот несколько статей, в которых говорится о последствиях использования сборщиков мусора для кэша:
Исходя из того, что я могу понять, основная проблема заключается в том, что системы сбора мусора обменивают пространство в памяти, чтобы избежать предварительного сбора. То же самое относится и к кеш-памяти. Как вы и предполагали, вещи в первом поколении, скорее всего, будут храниться в кеше, поэтому их распределение и сбор будут происходить намного быстрее, чем что-либо в основной памяти, или выгружаться на диск. Основной проблемой является размер первого поколения относительно размера вашего кэша. Если ваш кэш заполняется раньше, чем первое поколение, вы начинаете терять эти преимущества, так как промахи начинают накапливаться.
источник
У всех сборщиков мусора есть очень сложный аспект, который может быть приукрашен в некоторых описаниях, а именно «полное сканирование» или «полный сбор». Периодически, случайно, периодически они должны сканировать все объекты. коллекторы поколений лучше откладывают полное сканирование и минимизируют его продолжительность, но это все еще необходимо.
Коллектор поколений сосредоточится на том, что иногда называют «детским» пространством, но в конечном итоге / неизбежно придется собирать его на «старом» пространстве, вызывая полное сканирование памяти.
Это полное сканирование несовместимо практически со всеми схемами кэширования памяти и (особенно!) В том смысле, что почти все схемы кэширования / виртуализации памяти будут / должны плохо работать при любом повышении производительности в этом случае.
Таким образом, ключевым ответом на этот вопрос является то, как часто запускается полное сканирование, и насколько «плох» его эффект, когда это происходит, и можно ли это терпеть. это сводится к более зависимому от приложения свойству / вопросу.
Другими словами для «большинства» операций коллектора, кеш, вероятно, поможет ему (кеш и «молодое» пространство детской комнаты, как правило, будут перекрываться!), Но есть периодическая, прерывистая, возможная, неизбежная, тяжелая, может быть, даже «массивный» [деградирующий] всплеск производительности, когда пространство «старого поколения» заполнено полностью, а «частота попаданий» в кэш очень сильно ухудшится, так как многие объекты вне него все выбираются в узком цикле полным цикл сканирования / сбора. Другими словами, неизбежный периодический разрыв (где статистические оценки / средние показатели / тенденции производительности и т. Д. Вводят в заблуждение и неприменимы).
В настоящее время появляются некоторые новые системы сбора данных, которые предназначены для работы с базовыми системами управления памятью (кеширование / виртуализация). похоже, что исторические подходы, которые полностью разъединяют отдельные системы сбора, кэширования и виртуализации памяти, не будут работать так же хорошо, как подходы, которые объединяют / интегрируют / рассматривают все три аспекта вместе.
Посмотрите, например, сборщик мусора в кеше Zhou и Demsky.
источник