Сбор мусора JVM и архитектура памяти подкачки

Ответ 1

Вы правы, сборщик мусора и менеджер виртуальной памяти должны сотрудничать, иначе GC будет мусор системы. Такое сотрудничество GC/ядра было исследовано Мэтью Герцем, Йи Фэном и Эмери Д. Бергером. Чтобы получить хорошую производительность, им пришлось немного расширить ядро, а также настроить сборщик мусора.

В условиях повышенного давления на память их бенчмарк занял примерно 160 раз больше, используя GenMS Java GC. С новым GC, ориентированным на страницы, эталонный показатель был только в 1,6 раза медленнее. Другими словами, с правильно настроенным GC, коэффициент усиления 100 раз.

http://lambda-the-ultimate.org/node/2391

Ответ 2

Я собираюсь утверждать, что это не такая большая проблема, как вы думаете.

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

Я думаю, что это не вызывает беспокойства по нескольким причинам: во-первых, потому что современные JVM используют коллекторы коллекций, и большинство объектов никогда не выходят из молодых поколений, которые почти гарантированно находятся в резидентном наборе.

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

Третья причина (и может быть больше) заключается в том, что JVM (по крайней мере, Sun JVM) использует коллекцию с меткой-разверткой. Таким образом, после GC активные объекты в куче занимают меньшее количество страниц, снова увеличивая количество RSS. Это, кстати, является основным драйвером для приложений Swing, которые явным образом называют System.gc(), когда они сводятся к минимуму: путем уплотнения кучи, там меньше, чтобы поменять местами, когда они снова будут увеличены.

Кроме того, узнайте, что фрагментация кучи объектов C/С++ может стать экстремальной, а молодые объекты будут посыпаны среди старых, поэтому RSS должен быть больше.

Ответ 3

Я не эксперт, но какая-то коллективная сборка мусора должна немного помочь. Страницы, которые агрессивно меняются местами, скорее всего, содержат старые объекты, а не более новые, поэтому gc, естественно, будет касаться их реже.

Я также задал бы встречный вопрос: существуют ли какие-либо алгоритмы подкачки unix, которые представляют сборку мусора? Если какая-то страница перемещается в память на регулярной (если не часто) основе, то, возможно, это не такой замечательный кандидат, который должен быть отброшен в пользу большего дискового кэша; -)

Ответ 4

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

Имейте в виду, что это, как правило, настраиваемый параметр - vm.swappiness для ядра Linux, например. Вы можете прочитать статью в блоге, которую я написал об этом, если вы хотите получить более подробную информацию о настройке подкачки на Linux.

Существуют ли какие-либо алгоритмы сбора мусора для поискового вызова?

Алгоритмы сбора мусора, как правило, предназначены для очень широкого спектра возможных программ в качестве входных данных и для работы в большом количестве возможных сред; их дизайн должен учитывать это. Я думаю, что было бы очень сложно сделать "gg-алгоритм с поддержкой поискового вызова", который был бы в целом полезен. Если вы пишете один для очень специализированной среды, где вы можете блокировать вещи, тогда я думаю, что у вас будет неплохой шанс создать хороший результат.

Ответ 5

В этот день и в возрасте программы пейджинга - действительно плохая идея. Память очень дешевая.

FWIW, если вы работаете на ПК у производителя, которому нравится несколько раз заряжаться по шансам на память, у Windows Vista есть алгоритм прогностического пейджинга, который работает достаточно хорошо (возможно, единственное, что делает ОС хорошо).