Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
xueming.shen at oracle.com
Fri Jan 11 05:47:20 UTC 2013
(1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here
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
simply "return cr" at ln#193, without another "if".
(3) change in encode(char, int, int, byte) does not appear to be
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
of some "small" buf/array encoding? I'm a little concerned that the
slow down the small size buf/array encoding. There is a simple benchmark
en/decoding at test/sun/nio/cs/StrCodingBenchmark.
On 1/8/13 3:18 PM, Vladimir Kozlov wrote:
> 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.
More information about the core-libs-dev