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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

---

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

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

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

---

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

Я не верю в кеш-память с ограничением памяти).

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

---

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

Я не верю в кеш-память с ограничением памяти).

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

---

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

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

---

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

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

---

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