Soporte para cadenas comprimidas que se eliminan en HotSpot JVM?

En esta página de Oracle Java HotSpot VM Options , lista -XX:+UseCompressedStrings como disponible y -XX:+UseCompressedStrings manera predeterminada. Sin embargo, en la actualización 29 de Java 6, está desactivada por defecto y en la actualización 2 de Java 7 informa una advertencia

 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseCompressedStrings; support was removed in 7.0 

¿Alguien sabe el pensamiento detrás de eliminar esta opción?


ordenando líneas de un enorme archivo.txt en java

Con -mx2g , este ejemplo tomó 4.541 segundos con la opción activada y 5.206 segundos sin ella en la actualización 29 de Java 6. Es difícil ver que tenga un impacto en el rendimiento.

Nota: Java 7 actualización 2 requiere 2.0 G mientras que Java 6 actualización 29 sin cadenas comprimidas requiere 1.8 GB y con cadena comprimida requiere solo 1.0 GB.

Originalmente, esta opción se agregó para mejorar el rendimiento de SPECjBB. Las ganancias se deben a los requisitos de ancho de banda de memoria reducido entre el procesador y DRAM. Cargar y almacenar bytes en el byte [] consume 1/2 del ancho de banda en comparación con los caracteres en el carácter [].

Sin embargo, esto tiene un precio. El código debe determinar si la matriz interna es un byte [] o un char []. Esto lleva tiempo de CPU y si la carga de trabajo no está restringida en el ancho de banda de la memoria, puede causar una regresión de rendimiento. También hay un precio de mantenimiento del código debido a la complejidad añadida.

Debido a que no hubo suficientes cargas de trabajo similares a la producción que mostraron ganancias significativas (excepto tal vez SPECjBB), se eliminó la opción.

Hay otro ángulo para esto. La opción reduce el uso del montón. Para Cadenas aplicables, reduce el uso de memoria de esas Cadenas en 1/2. Este ángulo no se consideró en el momento de la eliminación de la opción. Para las cargas de trabajo que tienen limitaciones de capacidad de memoria (es decir, tienen que ejecutarse con un espacio de almacenamiento dynamic limitado y el GC lleva mucho tiempo), esta opción puede resultar útil.

Si se pueden encontrar suficientes cargas de trabajo de producción limitadas para la capacidad de memoria para justificar la inclusión de la opción, entonces tal vez la opción vuelva a aparecer.

Editar 20/03/2013: un volcado de almacenamiento intermedio de servidor promedio usa el 25% del espacio en cadenas. La mayoría de las cuerdas son compresibles. Si la opción se reintroduce, podría ahorrar la mitad de este espacio (por ejemplo, ~ 12%).

Edit 10/03/2016: Una característica similar a las cadenas comprimidas vuelve en JDK 9 JEP 254 .

Como hubo votos, creo que no me faltaba algo obvio, así que lo he registrado como un error (al menos una omisión en la documentación)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129417

(Debería ser visible en un par de días)

Solo para agregar, para aquellos interesados ​​…

La interfaz java.lang.CharSequence (que java.lang.String implementa), permite representaciones más compactas de cadenas que UTF-16.

Las aplicaciones que manipulan muchas cadenas, probablemente deberían estar escritas para aceptar CharSequence , de modo que funcionen con java.lang.String o representaciones más compactas .

Las cadenas codificadas de 8 bits (UTF-8), o incluso de 5, 6 o 7 bits, o incluso comprimidas se pueden representar como CharSequence .

CharSequence s también puede ser mucho más eficiente de manipular: las subsecuencias se pueden definir como vistas (punteros) en el contenido original, por ejemplo, en lugar de copiar.

Por ejemplo, en árboles concurrentes , un árbol de sufijo de diez de las obras de Shakespeare, requiere 2 GB de RAM usando nodos basados ​​en CharSequence , y requeriría 249 GB de RAM si se usan char [] o nodos basados ​​en String.

Java 9 ejecuta las líneas de clasificación de un enorme archivo.txt en java dos veces más rápido en mi máquina que Java 6 y también solo necesita 1G de memoria ya que tiene -XX:+CompactStrings habilitado por defecto. Además, en Java 6, las cadenas comprimidas solo funcionaron para los caracteres ASCII de 7 bits, mientras que en Java 9, es compatible con Latin1 (ISO-8859-1). Algunas operaciones como charAt(idx) pueden ser un poco más lentas. Con el nuevo diseño, también podrían soportar otras codificaciones en el futuro.

Escribí un boletín sobre esto en The Java Specialists ‘Newsletter .

En OpenJDK 7 (1.7.0_147-icedtea, Ubuntu 11.10), la JVM simplemente falla con un

Opción VM no reconocida ‘UseCompressedStrings’

cuando JAVA_OPTS (o línea de comando) contiene -XX:+UseCompressedStrings .

Parece que Oracle realmente eliminó la opción.