Siguiendo mi pregunta sobre si el CLR could use compressed pointers, la respuesta fue que no tiene sentido. Aún así, algunas JVM lo están implementando, entonces, ¿cuáles son los beneficios concretos de esta optimización, ya que ganar 4 bytes no parece valer la pena?¿Cuál es el propósito de los punteros de objetos comprimidos?
Hay un gran valor en las referencias comprimidas. Primero, en x86, los modos de 64 bits desbloquean 8 nuevos registros para ser usados, lo cual es una gran ganancia de rendimiento. En segundo lugar, el uso de encabezados de 4 bytes en lugar de 8 bytes/punteros de objeto mejora significativamente la eficacia de la memoria caché. Vemos ventajas en el mundo real en IBM Java del orden de ~ 5-10% con respecto a una JVM "completa" de 64 bits (su kilometraje variará). Esto hace que moverse a montones "pequeños de 64 bits" sea algo sencillo e indoloro, superando el límite de memoria de ~ 2 gb en las JVM de 32 bits. (el límite real de 32 bits podría estar entre 1700mb y ~ 3.7gb dependiendo del SO).
Si su objetivo principal es evitar colecciones de basura por completo, o al menos tener ejecuciones de GC menos frecuentes, vale la pena, ya que puede conducir a huellas de memoria sustancialmente inferiores.
Puede obtener 4 bytes de cada referencia de objeto. Si el objeto tiene más referencias, es común en el objeto java, puede guardar más memoria. El tamaño pequeño del objeto podría causar 2 resultados, primero, el tiempo de pausa del GC se reduce. Segundo, la tasa de aciertos de caché aumenta. Así que la aplicación Java podría obtener una mejora en el rendimiento. Para la prueba comparativa, habilitar CompressedOops podría mejorar el rendimiento en un 5% ~ 10%.