Что делает флаг HotSpot JVM -XX:+UseCompressedOops и когда его следует использовать? Какие различия в производительности и использовании памяти я увижу при использовании его в 64-разрядном экземпляре Java (по сравнению с его отсутствием)?
Что делает флаг JVM UseCompressedOops и когда его следует использовать?
comment
Он сжимает 64-битные указатели. Вы увидите уменьшение раздувания памяти из-за увеличения размера указателя, меньше времени, затрачиваемого на сборщик мусора, возможно, небольшое падение производительности. jdk1.6.0_22 была последней JVM Sun, у которой этот флаг был отключен по умолчанию.
- person sjr schedule 15.06.2012
comment
См. blog.juma.me.uk/2008/10/14/
- person Vadzim schedule 15.06.2012
Ответы (1)
В большинстве HotSpot JVM за последний год он был включен по умолчанию. Этот параметр позволяет сделать ссылки 32-разрядными в 64-разрядной JVM и получить доступ к куче размером около 32 ГБ. (может использоваться более 32-битных указателей) (у вас также может быть почти неограниченная память вне кучи). Это может сэкономить значительный объем памяти и потенциально повысить производительность.
Если вы хотите использовать эту опцию, я предлагаю вам обновить ее до версии, в которой она включена по умолчанию, так как могла быть веская причина, например, ошибки, почему она не была включена ранее. Попробуйте Java 6, обновление 23 или Java 7, обновление 5.
Короче говоря, не включайте его, используйте версию, в которой он включен по умолчанию.
Обновлять:
В Java 8 у вас есть возможность установить -XX:ObjectAlignmentInBytes=, и на самом деле, если размер кучи равен 64 ГБ, он будет использовать -XX:ObjectAlignmentInBytes=16 и по-прежнему будет использовать 32-битные ссылки.
person
Peter Lawrey
schedule
15.06.2012
Я прочитал эту статью: community.oracle.com/message/10019916, в которой говорится, что мы всегда должны используйте этот флаг вручную, даже если он включен по умолчанию. Есть предположения?
- person vanval; 12.11.2014
@vanval Это рекомендуется, если вы используете
JE cache Это потому, что невозможно определить, используете ли вы сжатие oops или нет по какой-то причине. Я могу придумать несколько методов, которые могут сказать вам об этом, кстати. Вам не нужно указывать его в командной строке IMHO, если вы не хотите, чтобы JVM вышла из строя, если она не включена. например у вас есть куча 64 ГБ на Java 8.
- person Peter Lawrey; 12.11.2014
Я только что провел несколько тестов на Win8 x64 i7-4702MQ JDK 8 u40 с 7 ГБ xms и xmx. Из 7 ГБ 5,4 ГБ используются большим деревом, загруженным из базы данных Access. Моя точка зрения такова: ручное указание флага -XX:+UseCompressedOops приводит к снижению производительности на 20% (при генерации большого дерева) и еще 1 (с 3 до 4) длительной паузе GC (с GC по умолчанию). Вы либо воспринимаете это как снижение производительности, либо как увеличение паузы GC. В любом случае, это было на 20% медленнее.
- person zmirc; 07.05.2015
Каждое приложение имеет свою собственную память и профиль использования. В нашем случае настольное приложение, полученное из 32-битной jvm, флаг +UseCompressedOops спасает ситуацию, поскольку он поддерживает использование памяти достаточно низким, чтобы поместиться на старой машине клиента с 4 ГБ, и повышает производительность на 30% по сравнению с 32-битной jvm.
- person Alex Byrth; 09.11.2016
