Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 (original) (raw)

Xueming Shen xueming.shen at oracle.com
Fri Jan 11 05:47:20 UTC 2013

Vladimir,

(1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should not change the real "sp" after "break+return". (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and simply "return cr" at ln#193, without another "if". (3) change in encode(char[], int, int, byte[]) does not appear to be correct. I doubt the slen will get calculated correctly for next round of encoding, if "len" is used for the src side length without considering the "ret". Maybe ln#259 should be slen = Math.min(sl -sp, dst.length - dp);

I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance of some "small" buf/array encoding? I'm a little concerned that the overhead may slow down the small size buf/array encoding. There is a simple benchmark for String en/decoding at test/sun/nio/cs/StrCodingBenchmark.

-Sherman

On 1/8/13 3:18 PM, Vladimir Kozlov wrote:

http://cr.openjdk.java.net/~kvn/6896617jdk/webrev

Move encoding loop into separate method for which VM will use intrinsic on x86. I want to get agreement on this jdk change before I submit VM part. This gives +1.6% performance improvement on SPECjAppServer2004 on x86. Note, even without intrinsic (on other platforms) JIT will produce better code for this loop. Thanks, Vladimir

More information about the core-libs-dev mailing list