Java 32bit и 64-разрядный оптимизационный режим (-XX: -UseCompressedOops)

Я пытаюсь предсказать изменение требований к памяти кучи в случае, когда я запускаю приложение Java без изменений в JVM, настроенном на использование более 32 ГБ памяти.

Я ожидаю, что накладные расходы памяти будут значительными для того же количества "полезных" объектов, которые хранятся в памяти сразу после перенастройки параметра Xmx с 32 ГБ на 64 ГБ.

Я попытался смоделировать и оценить разницу, применив -XX:-UserCompressedOps на моей локальной машине, работающей с небольшой кучей (8 ГБ), но пока не смог прийти к выводу. Согласно расчетам времени выполнения, мои объекты занимают одинаковый объем памяти в обоих случаях. Используемая куча с выключенной оптимизацией, как правило, немного больше, но не в два раза больше, как я мог ожидать, прочитав некоторые объяснения.

В моем случае я просто храню большое количество относительно больших объектов POJO 100-1K каждый в куче на весь срок службы программы.

Существует ли эмпирическое правило о том, как требования к памяти растут, просто пересекая ограничение 32 ГБ (когда оптимизация на 32 бита больше не применяется)?

Ответы

Ответ 1

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

Я понимаю, что отключение CompressedOops будет только удвоить размеры указателей (типы ссылок), а не примитивные типы, особенно не строки, байт-массивы и т.п. Поэтому, если в вашей куче преобладают массивы примитивных типов, тогда увеличение может быть трудно заметить.

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