RFR: JDK-8184947:,ZipCoder performance improvements

[Xueming Shen]

Hi,

Please help review the changes for j.u.z.ZipCoder/JDK-8184947 (which 
also includes
cleanup/improvement work in java.lang.StringCoding.java to speed up 
general String
coding performance, especially for UTF8).

issue: https://bugs.openjdk.java.net/browse/JDK-8184947
webrev: http://cr.openjdk.java.net/~sherman/8184947/webrev

jmh benchmark:
http://cr.openjdk.java.net/~sherman/8184947/ZipCodingBM.java
http://cr.openjdk.java.net/~sherman/8184947/StringCodingBM.java

Notes:

(1) StringCoding.de/encode() for new String()/String.getBytes() with 
default charset.

For historical reason the existing SC.decode(byte[], off, 
len)/encode(coder, val)
implementation has code to handle any "possible" UnsupportedEncodingExcetion
situation and turn to the slow "charset name" version of de/encode() for 
real work.
Given the fact that the Charset.defaultCharset() now returns UTF8 as the 
fallback
default charset if there is anything wrong to obtain a default charset 
(we did that in
jdk7 or 8?), there is no need actually to handle the UEE.  This also 
provides the
opportunity to use fastpath for stateless UTF8/88591/ASCII de/encode(). The
benchmark data for newString_xxx/ getBytes_xxx (which uses the default 
encoding,
UTF8  in this case) suggests a big speed up fo ascii-only String.

StringCodingBM         size)  Mode  Cnt   NEW Score   Error     OLD Score    Error  Units


getBytes_ASCII            16  avgt    5    21.155 ±   5.586      63.777 ±   54.262  ns/op
getBytes_ASCII            64  avgt    5    20.854 ±   6.237      98.988 ±   62.932  ns/op
getBytes_ASCII           256  avgt    5    38.291 ±   8.494     272.306 ±   77.951  ns/op
getBytes_Latin            16  avgt    5    80.968 ±  15.814      76.769 ±   38.512  ns/op
getBytes_Latin            64  avgt    5   163.078 ±  51.993     219.085 ±   42.665  ns/op
getBytes_Latin           256  avgt    5   759.548 ±  99.386     824.594 ±  763.735  ns/op
getBytes_Unicode          16  avgt    5    94.311 ±  22.189     124.185 ±   32.751  ns/op
getBytes_Unicode          64  avgt    5   289.603 ± 152.056     321.541 ±  103.703  ns/op
getBytes_Unicode         256  avgt    5  1253.098 ± 216.243    1201.667 ±  512.532  ns/op

newString_ASCII           16  avgt    5    33.273 ±  13.780      50.402 ±   17.574  ns/op
newString_ASCII           64  avgt    5    30.420 ±   6.207      84.989 ±   43.355  ns/op
newString_ASCII          256  avgt    5    54.391 ±  10.451     208.096 ±  102.716  ns/op
newString_Latin           16  avgt    5   115.606 ±   7.181     114.186 ±   36.310  ns/op
newString_Latin           64  avgt    5   393..710 ±  73.478    414.286 ±  176.837  ns/op
newString_Latin          256  avgt    5  1618.967 ± 289.044    1551.499 ±  487.904  ns/op
newString_Unicode         16  avgt    5   104.848 ±  32.694     127.558 ±   12.029  ns/op
newString_Unicode         64  avgt    5   377.894 ± 147.731     374.779 ±   53.028  ns/op
newString_Unicode        256  avgt    5  1557.977 ± 318.652    1457.236 ±  284.424  ns/op


(2) updated to "fast path" UTF8/8859-1/ASCII in all de/coding operation, 
which are all
implemented in static /stateless methods. (benchmark for MS932 [4] 
provide to make
sure no regression for "other" charsets)

(3) added "fast path" for "ascii-only' bytes for utf8 
encoding/getBytes(). The benchmark
[1] suggests a big speedup for ascii-only getBytes() with limited cost 
to non-ascii-only
cases. (this helps big for (4), the ZipCoder situation, which mainly 
uses ascii only).

(4) java.util.zip.ZipCoder

This is where this patch actually started from. As the rfe suggested we 
are now using
byte[] as the internal storage for the String class, the optimization we 
put in ZipCoder
for UTF8 (which uses the byte[]/char[] interface of out UTF8 
implementation to help
avoid the relatively heavy ByteBuffer/CharBuffer coding interface) now 
appears to be
not that "optimized". The to/from char[] copy/paste has become a waste.

ZipCoder  implementation can't use new String/String.getBytes() directly 
because of the
the different malformed/unmappable character handing requirement. The 
proposed
change here is to add a pair of special new String()/String.getBytes() 
in StrngCoding
class to throw IAE instead of silent replacement, via (yet another) 
SharedSecrets
interface. This brings us much faster de/encoding (30%-50% speed up) and 
much less
memory usage (no more unnecessary byte[]/char[] allocation and in 
default mode, there
is only ONE utf8 ZipCoder), on all  "Jar/ZipEntry" related access 
operations.

ZipCodeBenchMark [latest]
     * "New Score" is with the patch
     * getEntry() is mainly String.getBytes(), entries()/stream() is 
mainly new String(bytes)).

                Mode  Cnt     New Score   Error      Old Score         Units
jf_entries     avgt   20     0.582 ±    0.036      0.953 ±   0.108   ms/op
jf_getEntry    avgt   20     1.506 ±    0.158      2.052 ±   0.171   ms/op
jf_stream      avgt   20     0.698 ±    0.060      0.940 ±   0.067   ms/op
zf_entries     avgt   20     0.691 ±    0.057      0.917 ±   0.080   ms/op
zf_getEntry    avgt   20     1.459 ±    0.180      2.081 ±   0.161   ms/op
zf_stream      avgt   20     0.626 ±    0.074      0.909 ±   0.075   ms/op



Thanks,
Sherman

[1] http://cr.openjdk.java.net/~sherman/8184947/StringCoding.utf8
[2]http://cr.openjdk.java.net/~sherman/8184947/StringCoding.8859_1
[3] http://cr.openjdk.java.net/~sherman/8184947/StringCoding.ascii
[4]http://cr.openjdk.java.net/~sherman/8184947/StringCoding.ms932
[5] http://cr.openjdk.java.net/~sherman/8184947/ZipCoding.bm