Переполнение памяти в 32-битном или 64-битном режиме оптимизации Java (-XX:-UseCompressedOops)
Я пытаюсь предсказать изменение требований к динамической памяти для случая, когда я запускаю свое приложение Java без изменений в JVM, настроенной на использование более 32 ГБ памяти.
Я ожидаю, что будут существенные накладные расходы памяти для того же количества "полезных" объектов, которые я храню в памяти сразу после перенастройки параметра Xmx с 32 ГБ до 64 ГБ.
Я попытался смоделировать и оценить разницу, применяя -XX:-UserCompressedOps на моей локальной машине, работающей с небольшой кучей (8 ГБ), но не мог прийти к выводу еще. Согласно вычислениям во время выполнения мои объекты занимают одинаковое количество памяти в обоих случаях. Используемая куча с отключенной оптимизацией имеет тенденцию быть немного больше, но ни в коем случае не в два раза больше, как я мог ожидать, читая некоторые объяснения.
В моем случае я просто храню большое количество относительно больших объектов POJO по 100-1K каждый в куче на протяжении всего времени жизни программы.
Существует ли эмпирическое правило о том, как увеличиваются требования к памяти, просто превышая ограничение в 32 ГБ (когда 32-разрядные оптимизации больше не применяются)?
1 ответ
но никак не в два раза больше, чем я мог ожидать, читая некоторые объяснения.
Насколько я понимаю, отключение CompressedOops будет только удваивать размеры указателя (ссылочные типы), а не примитивные типы, особенно не Strings, байтовые массивы и тому подобное. Так что, если в вашей куче преобладают массивы примитивных типов, то увеличение может быть трудно заметить.
Требования выравнивания также делают различия в размере не такими прямыми, потому что более крупные указатели могут просто заполнить некоторые выравнивающие отступы.