Le support pour les chaînes compressées est-il abandonné?

Question

Sur cet oracle page Java HotSpot VM Options il répertorie -XX:+UseCompressedStrings comme étant disponible et activée par défaut. Toutefois, dans Java 6 update 29 son off par défaut et dans Java 7 update 2 il signale un avertissement

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

Personne ne sait le raisonnement à la base de la suppression de cette option?

---

trier les lignes d'un énorme file.txt en java

Avec -mx2g, cet exemple pris 4.541 secondes avec l'option de sur et 5.206 deuxième avec en Java 6 update 29. Il est difficile de voir qu'elle a des répercussions sur les performances.

Remarque: Java 7 update 2 nécessite 2.0 G alors que Java 6 update 29 sans texte compressé nécessite 1,8 GO et comprimé chaîne nécessite seulement 1,0 GO.

Answer 1

A l'origine, cette option a été ajoutée pour améliorer SPECjBB performance. Les gains sont dus à la réduction de bande passante de la mémoire entre le processeur et de la mémoire DRAM. Le chargement et le stockage des octets dans le byte[] consomme 1/2 de la bande passante et les caractères de la char[].

Toutefois, cela vient à un prix. Le code doit déterminer si le tableau interne est un byte[] ou char[]. Cela prend du temps CPU et si la charge de travail n'est pas de la mémoire de la bande passante limitée, il peut provoquer une régression de la performance. Il y a aussi une gestion des codes de prix à cause de la complexité.

Car il n'y avait pas assez de production-comme des charges de travail qui a montré des gains importants (à l'exception peut-être SPECjBB), l'option a été supprimée.

Il ya un autre angle à ce. L'option permet de réduire l'utilisation du tas. Pour les Chaînes, il réduit l'utilisation de la mémoire de ces Chaînes par 1/2. Cet angle n'était pas considérée, à l'époque de l'option de retrait. Pour les charges de travail de mémoire de capacité limitée (c'est à dire à exécuter avec peu d'espace de tas et GC prend beaucoup de temps), cette option peut s'avérer utile.

Si suffisamment de mémoire capacité limitée de production-comme les charges de travail peuvent être trouvées pour justifier l'option de l'inclusion, alors peut-être que l'option sera ramené.

Edit 3/20/2013: Un serveur moyen de tas de vidage utilise 25% de l'espace sur les Cordes. La plupart des Chaînes sont compressibles. Si l'option est réintroduit, il peut économiser de la moitié de cet espace (par exemple, ~12%)!

Answer 2

Juste pour ajouter, pour ceux qui sont intéressés...

Le java.lang.CharSequence interface ( java.lang.String outils), permet à plus compact représentations de Chaînes que UTF-16.

Les applications qui manipulent beaucoup de chaînes, devrait probablement être écrite pour accepter CharSequence, tels qu'ils allaient travailler avec java.lang.String, ou plus compact des représentations.

8 bits (UTF-8), ou même 5, 6, ou 7 bits codés, ou même compressés les chaînes de caractères peuvent être représentés en tant que CharSequence.

CharSequences peuvent également être beaucoup plus efficace pour manipuler - sous-séquences peuvent être définis comme des points de vue (pointeurs) sur le contenu d'origine par exemple, au lieu de les copier.

Par exemple, dans des arbres, un suffixe de l'arbre de dix pièces de Shakespeare, nécessite 2 GO de RAM à l'aide de CharSequence-nœuds, et nécessiterait 249GB de RAM si vous utilisez char[] ou Chaîne de nœuds.

Answer 3

Comme il y avait eu plus de votes, je pensais qu'il ne me manquait rien d'évident, alors je l'ai consigné comme un bogue (au moins une omission dans la documentation).

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

(Doit être visible dans quelques jours)

Answer 4

Dans OpenJDK 7 (1.7.0_147-icedtea, Ubuntu 11.10), il échoue simplement avec un

Option de VM non reconnue 'UseCompressedStrings'

lorsque JAVA_OPTS (ou la ligne de commande) contient -XX:+UseCompressedStrings .

Il semble que Oracle ait vraiment supprimé cette option.