RFR: JDK-8184947:,ZipCoder performance improvements (original) (raw)

Xueming Shen xueming.shen at oracle.com
Wed Dec 13 15:08:16 UTC 2017

Thanks Martin!

webrev has been updated accordingly.

http://cr.openjdk.java.net/~sherman/8184947/webrev

I will try to see if I can do something for your canDecode(...) idea. I'm still have a relative big change in repo (mainly for the Strting(ByteBuffer ...) which might move all those utf8/asci/iso8859 back to where they were in sun.nio.cs.

I'm running tests locally and on our mach5 system now. If everything comes back positively, with in next 50 minutes :-) I will try to push what I have right now into the jdk10.

Thanks, Sherman

On 12/13/17, 2:28 AM, Martin Buchholz wrote:

Sorry, I haven't had the time I would like to review. It would be good to make jdk10. I keep wishing what we do for performance here wouldn't get so messy. I keep thinking we should add some methods to the public Charset classes, e.g. canDecode(byte[], int, int) with one general purpose implementation and high-performance implementations for UTF-8, ASCII, Latin1 ASCII checking via hasNegatives has some hotspot help and that should be available as a high performance public API somewhere. One possibility is my canDecode suggestion.

+ if (b>= 0) + putChar(dst, dp++, (char)b); + else + putChar(dst, dp++, repl); why not coalesce into putChar(dst, dp++, (b >= 0) ? (char)b : repl)

More information about the core-libs-dev mailing list