RFR: 8231717: Improve performance of EBCDIC charset decoding for COMPACT_STRINGS

[Roger Riggs]

Hi Andrew,

This would seem to have an impact on the performance of every Decoder 
constructor
because it determines dynamically the isAlwaysCompactable attribute.
Are there regressions in the non-EBCDIC cases?

Did your performance tests include the constructor overhead?

The isASCIICompatible case is handled by checking for negatives only 
when needed.

Unless the information is used more than once it looks like you've moved 
the computation
from StringCoding hasNegatives to the Decoder constructor.

Is there a change that would benefit both the isASCIICompatible case and 
EBCDIC?

Is there a reason you didn't add the isAlwaysCompactable method to the 
existing ArrayDecoder interface.
I don't think there there is a need for a new interface.

Thanks, Roger

On 10/2/19 4:10 AM, Andrew Leonard wrote:
> Hi,
> Please can I request a review of this performance enhancement for EBCDIC
> (and any SingleByte, always compactable) charsets? I've explained the
> theory in the bug (https://bugs.openjdk.java.net/browse/JDK-8231717), but
> essentially it optimizes any SingleByte charset that is always compactable
> due to all mappings being to <=0xff and avoids unnecessary char[] to
> internal Latin1 byte[] arraycopy as a result. This leads to up to a 100%
> performance gain for decoding these charsets.
> I have run the complete tier1 and also the complete sun/nio/cs testcases
> successfully.
>
> Webrev: http://cr.openjdk.java.net/~aleonard/8231717/webrev.00/
>
> Thoughts and comments welcome please?
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> internet email: andrew_m_leonard at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>