RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets

[Claes Redestad]

On Tue, 9 Feb 2021 19:14:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This refactor some `sun.nio.cs.ext` charsets, such as ISO-2022-CN-GB, ISO-2022-CN-CNS, ISO-2022-KR and a few others to use static rather than per-instance auxiliary decoders. Doing so reduce overheads of calling `charset.newDecoder()`. This reduce or eliminate regressions on `new String(byte[], String)` operations due the removal of thread-local decoder caching in [JDK-8259842](https://bugs.openjdk.java.net/browse/JDK-8259842)
>> 
>> Most ISO-2022 Charsets define a specialized decoder already. The `ISO2022.Decoder` class was only used by `ISO2022_KR`, so folding it into that implementation and simplifying the code brings a rather significant speed-up, both to decoder creation and on actual decoding.
>> 
>> Testing: tier1-3, manual runs of sun.nio.cs tests
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template line 116:
> 
>> 114:             int sp = src.arrayOffset() + src.position();
>> 115:             int sl = src.arrayOffset() + src.limit();
>> 116: 
> 
> I see these are removed from encode/decodeArrayLoop(s). Any reason behind those?

My IDE was marking the next line as redundant since `sp <= sl` will always be true. `buffer.position() <= buffer.limit()` is an invariant that I don't think we need to assert against here, and I think it's just been copy-pasted around mindlessly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2480