Размер кучи больше -Xmx

Question

Я установил начальный и максимальный размер кучи Java до 256 МБ, используя -Xms256m and -Xmx256m JVM options. В журнале GC (с использованием -XX:+PrintHeapAtGC) указано, что размер кучи составляет 251904K (246 МБ), который равен smaller than the minimum heap size, -Xms256m (см. Последнюю строку журнала). Однако это связано с тем, что the stated heap size is the available heap size, который не включает the unavailablefrom space.

Когда я вручную включить недоступный из пространства памяти, полученный размер кучи 262656K (256.5MB), который немного больше, чем максимальный размер кучи, -Xmx (по 512 КБ):

[heap size] = [eden space size] + [from space size] + [to space size] + [OldGen size] 
    262656K =  66048K  +  10752K  +  10752K  + 175104K 

Почему размер кучи немного больше, чем максимальный размер кучи, -Xmx?

Answer 1

Во-первых, это кажется странным, но, как обычно, нет никакой магии. Единственный способ узнать ответ - глубже: до openjdk sources. Просто проверьте и попробуйте grep: grep -r "Xmx" .

Будет много тестов, но они нам не интересны. Два файла могут помочь нам: /vm/runtime/arguments.cpp и /vm/memory/collectorPolicy.cpp

Давайте рассмотрим аргументы.cpp: существует только простой синтаксический анализ параметров, например. для -Xmx256M это будет что-то вроде result = 256 * 1024 * 1024 (с некоторыми вставками от меня). Поэтому ответа на наш вопрос нет.

Но переменная MaxHeapSize здесь инициализируется, поэтому мы можем попытаться ее найти. Реальное использование MaxHeapSize можно найти в нашем /vm/memory/collectorPolicy.cpp (где Xmx используется только в комментариях), где все размеры генерации кучи выбираются некоторой политикой.

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

Параметры JVM по умолчанию для отношений поколений: -XX:NewRatio=2 (отношение размеров молодого поколения: старый ген) и -XX:SurvivorRatio=8 (соотношение эден: выживших). Но размер кучи не всегда делится на 3, 9 или что-то еще, поэтому должно быть какое-то округление. И, как я упоминал ранее, всегда должно быть некоторое выравнивание.

Итак, наконец, ответ: эти размеры являются единственными возможными размерами, которые удовлетворяют условиям поколений и выравниванию. Это не всегда возможно, если сумма этих значений равна Xmx значение параметра.

Если вас интересуют подробности, вы можете найти логику для округления -XX:NewRatiohere по методу scale_by_NewRatio_aligned. Попробуйте найти ту же логику около -XX:SurvivorRatio самостоятельно :)