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

[Xueming Shen]

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/6896617_jdk/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