CMS сборщик мусора - когда он запускается?

Question

Я запутался в двух параметрах, которые могут контролировать, когда включается коллектор CMS:

MaxHeapFreeRatio (По умолчанию 70%)

CMSInitiatingOccupancyFraction (более 90% по умолчанию)

Что конкретно означает каждый из этих параметров? Когда коллектор запускается (фаза маркировки) и собирается (фаза подметания)?

Answer 1

CMSInitiatingOccupancyFraction решает, когда CMS включается (для того, чтобы эта опция была эффективной, вы также должны установить -XX:+UseCMSInitiatingOccupancyOnly). MaxHeapFreeRatio опция для определения размеров поколений

Смотри например...

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

Обычно одновременный сбор данных не может быть ускорен, но он может быть запущен раньше. Параллельная коллекция запускается, когда процент выделенного пространства в старом поколении пересекает порог. Этот порог рассчитывается на основе общего опыта с одновременным коллектором. Если происходят полные коллекции, одновременные коллекции, возможно, потребуется запустить раньше. Флаг командной строки CMSInitiatingOccupancyFraction можно использовать для установки уровня, на котором начинается сбор. Его значение по умолчанию составляет примерно 68%. Командная строка для настройки значения -XX:CMSInitiatingOccupancyFraction=<percent>

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

По умолчанию виртуальная машина увеличивает или уменьшает кучу в каждой коллекции, чтобы попытаться сохранить пропорцию свободного пространства для живых объектов в каждой коллекции в пределах определенного диапазона. Этот целевой диапазон задается в процентах параметрами -XX:MinHeapFreeRatio=<minimum> а также -XX:MaxHeapFreeRatio=<maximum>, а общий размер ограничен снизу -Xms и выше -Xmx,

.. или же..

http://www.petefreitag.com/articles/gctuning/

-XX:MaxHeapFreeRatio - когда процент свободного пространства в поколении превысил это значение, поколение будет сокращаться, чтобы соответствовать этому значению. По умолчанию 70

РЕДАКТИРОВАТЬ: Я провел несколько симуляций с тестовой программой, которая просто случайным образом создает карты байтовых массивов и копирует их вокруг. Я заметил, что а) значение дроби не соблюдается - в частности, при консервативном значении (скажем, 50) начальная стадия оценки CMS превысила 50% заполненности, обычно около 70-80% и b) тем не менее, меньшие значения дроби сделали CMS начальная стадия произошла раньше (использовалась программа -Xmx1536m -Xmx1536m -XX:NewSize=512m -XX:+UseConcMarkSweepGc + gc logging и два тестовых параметра)

Я также нашел старый отчет об ошибке, относящийся к этому: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089