Понимание внутренних свойств фрагментации процесса Hotspot JVM

Для распределений на кучу и вне кучи. On-heap - в контексте трех основных сборщиков мусора: CMS, Parallel Old и и G1.

То, что я знаю (или думаю, что знаю) на данный момент:

  • распределения всех объектов (по-куче) округляются до 8-байтовой границы (или большей мощности 2, с настройкой -XX:ObjectAlignmentInBytes.
  • G1
    • Для распределений на куче, меньших размера региона (от 1 до 32 МБ, вероятно, вокруг размера кучи /2048), нет внутренней фрагментации, потому что нет необходимости, потому что распределитель никогда не "заполняет отверстия".
    • Для распределений большего размера региона он округляет распределение до размера региона. I. e. выделение области размером + 1 байт очень неудачно, оно отнимает почти 50% памяти.

  • Для CMS единственная релевантная информация, которую я нашел, -

    Естественно старые PLAB-схемы пространства имитируют структуру индексированного свободного списка. В каждом потоке выделяется определенное количество блоков каждого размера ниже 257 слов кучи (большой фрагмент, выделенный из глобального пространства).

    От http://blog.ragozin.info/2011/11/java-gc-hotspots-cms-promotion-buffers.html. Насколько я понимаю, "глобальное пространство" - это основное старое пространство.

Вопросы:

  • Правильны ли приведенные выше утверждения?
  • Каковы свойства фрагментации основного старого пространства в CMS? Что относительно распределений более чем "257 слов кучи"?
  • Как управлять старым пространством с помощью Parallel Old GC?
  • Использует ли Hotspot JVM распределитель системной памяти для распределений вне кучи или перенаправляет его с помощью специального распределителя?

UPD. Тема обсуждения: https://groups.google.com/forum/#!topic/mechanical-sympathy/A-RImwuiFZE

ОТВЕТЫ

Ответ 1

  • Насколько я понимаю, приведенные выше утверждения правильны, хотя бит в CMS не содержит большого контекста для его интерпретации.
  • CMS подвержена фрагментации (в ее старом пространстве, где работает CMS), что является одним из его основных недостатков. Если он фрагментирует слишком много, иногда может потребоваться остановить мир и выполнить полную метку, развертку и сжатие, чтобы удалить фрагментацию, что приводит к большой паузе в приложении. Именно этот недостаток часто упоминается как причина G1. Некоторые системы (например, HBase) специально выполняют большую часть своих распределений с блоками фиксированного размера, чтобы предотвратить или значительно сократить фрагментацию CMS, чтобы избежать длительных пауз в мире.
  • ParallelOldGC (или "Старый GC" вообще) не фрагментирует. Объекты переносятся на старую кучу, и когда она заканчивается из космоса, запускается полный метка, развертка, компактный цикл. Он может делать этот полный GC быстрее, чем любой другой распределитель, но с типичным временем работы 1 секунду на 2 ГБ кучи, это может быть слишком большим для больших кучи или приложений с чувствительностью к задержкам.
  • Hotspot использовал различные стратегии для распределения вне кучи в зависимости от цели. Выделение собственных байт-буферов отличается от собственного распределения для скомпилированного кода или профилирующих данных. Я не могу отвечать с полномочиями здесь ни на какие подробности, но могу только предположить, что большая часть этого не использует системный распределитель, иначе Hotspot не будет работать так же хорошо, как и он. Кроме того, есть параметры, которые можно настроить таким образом, чтобы управлять некоторым из этого пространства, например. -XX:ReservedCodeCacheSize, который предполагает, что такая область памяти управляется посредством косвенной передачи, а не напрямую через системный распределитель. Короче говоря, я был бы весьма удивлен, если бы системный распределитель был напрямую использован для любого мелкозернистого выделения вообще в точке доступа.