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
