是否支持在HotSpot JVM中删除压缩字符串？ [英] Support for Compressed Strings being Dropped in HotSpot JVM?
问题描述
在此Oracle页面上 Java HotSpot VM Options ，它将 -XX：+ UseCompressedStrings 列为可用，默认情况下为on。但是在Java 6更新29中，默认情况下它是关闭的，在Java 7更新2中它会报告警告
On this Oracle page Java HotSpot VM Options, it lists -XX:+UseCompressedStrings as being available and on by default. However in Java 6 update 29, it is off by default and in Java 7 update 2 it reports a warning
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseCompressedStrings; support was removed in 7.0
有没有人知道删除此选项背后的想法？
Does anyone know the thinking behind removing this option?
使用 -mx2g ，此示例在选项打开时耗时4.541秒，在Java 6更新29中取消5.206秒。很难看出它会影响性能。
With -mx2g, this example took 4.541 seconds with the option on and 5.206 second with it off in Java 6 update 29. It is hard to see that it impacts performance.
注意：Java 7更新2需要2.0 G，而没有压缩字符串的Java 6更新29需要1.8 GB，压缩字符串只需要1.0 GB。
Note: Java 7 update 2 requires 2.0 G whereas Java 6 update 29 without compressed strings requires 1.8 GB and with compressed string requires only 1.0 GB.
推荐答案
最初，添加了此选项以改善SPECjBB性能。增益是由于处理器和DRAM之间的内存带宽需求减少。在字节[]中加载和存储字节消耗带宽的1/2与char []中的字符相比。
Originally, this option was added to improve SPECjBB performance. The gains are due to reduced memory bandwidth requirements between the processor and DRAM. Loading and storing bytes in the byte[] consumes 1/2 the bandwidth versus chars in the char[].
然而，这需要付出代价。代码必须确定内部数组是byte []还是char []。这需要CPU时间，如果工作负载不是内存带宽受限，则可能导致性能下降。由于增加的复杂性，还有一个代码维护价格。
However, this comes at a price. The code has to determine if the internal array is a byte[] or char[]. This takes CPU time and if the workload is not memory bandwidth constrained, it can cause a performance regression. There is also a code maintenance price due to the added complexity.
因为没有足够的类似生产的工作负载显示出显着的收益（除了SPECjBB），所以已被删除。
Because there weren't enough production-like workloads that showed significant gains (except perhaps SPECjBB), the option was removed.
还有另一个角度。该选项可减少堆使用量。对于适用的字符串，它会将这些字符串的内存使用量减少1/2。在删除选项时不考虑该角度。对于内存容量约束的工作负载（即必须以有限的堆空间运行并且GC需要花费大量时间），此选项可以证明是有用的。
There is another angle to this. The option reduces heap usage. For applicable Strings, it reduces the memory usage of those Strings by 1/2. This angle wasn't considered at the time of option removal. For workloads that are memory capacity constrained (i.e. have to run with limited heap space and GC takes a lot of time), this option can prove useful.
如果有足够的内存容量约束类似生产的工作负载可以证明该选项的包含，那么可能该选项将被带回。
If enough memory capacity constrained production-like workloads can be found to justify the option's inclusion, then maybe the option will be brought back.
编辑2013年3月20日：平均服务器堆转储使用Strings上25％的空间。大多数字符串都是可压缩的。如果重新引入该选项，则可以节省一半的空间（例如~12％）！
Edit 3/20/2013: An average server heap dump uses 25% of the space on Strings. Most Strings are compressible. If the option is reintroduced, it could save half of this space (e.g. ~12%)!
编辑2016年3月10日： A类似于压缩字符串的功能将在JDK 9 JEP 254 中回归。
Edit 3/10/2016: A feature similar to compressed strings is coming back in JDK 9 JEP 254.
这篇关于是否支持在HotSpot JVM中删除压缩字符串？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
