¿Qué hace el indicador UseCompressedOops JVM y cuándo debería usarlo?

¿Qué hace el indicador HotSpot JVM -XX:+UseCompressedOopsy cuándo debería usarlo? ¿Qué tipo de diferencias de rendimiento y uso de memoria veré cuando lo use en una instancia de Java de 64 bits (en lugar de no usarlo)?

— noahlz
fuente

Comprime punteros de 64 bits. Verá una reducción de la hinchazón de la memoria debido al mayor tamaño del puntero, menos tiempo dedicado a GC, tal vez una pequeña caída en el rendimiento. jdk1.6.0_22 fue la última JVM de Sun en tener esta bandera desactivada de forma predeterminada.

— sjr

Ver blog.juma.me.uk/2008/10/14/…

— Vadzim

La mayoría de HotSpot JVM en el último año lo ha tenido activado de forma predeterminada. Esta opción permite que las referencias sean de 32 bits en una JVM de 64 bits y accedan a cerca de 32 GB de pila. (más de los punteros de 32 bits pueden) (También puede tener una memoria de montón casi ilimitada). Esto puede ahorrar una cantidad significativa de memoria y mejorar potencialmente el rendimiento.

Si desea utilizar esta opción, le sugiero que actualice a una versión que la tenga activada de forma predeterminada, ya que puede haber una buena razón, como errores, por la que no estaba habilitada anteriormente. Pruebe la actualización 23 de Java 6 o la actualización 5 de Java 7.

En resumen, no lo enciendas, usa una versión que lo tenga activado por defecto.

Actualizar:

En Java 8 tiene la opción de establecer el -XX:ObjectAlignmentInBytes=y, de hecho, si tiene un tamaño de pila de 64 GB, utilizará -XX:ObjectAlignmentInBytes=16y seguirá utilizando referencias de 32 bits.

— Peter Lawrey
fuente

Leí este artículo: community.oracle.com/message/10019916 que establece que siempre debemos usar este indicador manualmente, incluso si está habilitado de forma predeterminada. ¿Alguna idea?

— Vanval

@vanval Eso se recomienda si está utilizando JE cache Esto se debe a que no puede determinar si está utilizando compresas o no por alguna razón. Puedo pensar en algunos métodos que pueden decirte esto por cierto. No debería necesitar especificarlo en la línea de comando en mi humilde opinión a menos que desee que la JVM falle si no está habilitada. por ejemplo, tiene un montón de 64 GB en Java 8.

— Peter Lawrey

Acabo de ejecutar algunas pruebas en Win8 x64 i7-4702MQ JDK 8 u40 con 7 GB xms y xmx, de los 7 GB, 5,4 GB son utilizados por un gran árbol cargado desde una base de datos de Access. Mi punto es: especificar manualmente el indicador -XX: + UseCompressedOops conduce a una disminución del 20% en el rendimiento (al generar el árbol grande) y 1 más (de 3 a 4) pausa de GC larga (con GC predeterminado). Puede tomarlo como una disminución en el rendimiento o como un aumento en la pausa de GC. De cualquier manera, fue un 20% más lento.

— zmirc

Cada aplicación tiene su propia memoria y perfil de uso. En nuestro caso, una aplicación de escritorio que proviene de 32bits jvm, la bandera + UseCompressedOops salva el día, ya que mantuvo el uso de memoria lo suficientemente bajo como para caber en la antigua máquina de 4gb del cliente y aumentó el rendimiento en un 30%, en comparación con 32bits jvm.

— Alex Byrth