<i18n dev> RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v2]

[Claes Redestad]

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

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> src/jdk.charsets/share/classes/sun/nio/cs/ext/ISO2022.java line 64:
> 
>> 62: 
>> 63:         protected final byte maximumDesignatorLength = 4;
>> 64: 
> 
> This implementation moved to KR concrete implementation class. IIUC, this is the default impl for generic ISO2022 spec, so I believe the code being here is more reasonable. Any performance gain by moving this to KR specific class?

The KR concrete impl is the only instantiation of this default impl - all other were already implementing specialized `Decoders` that does not inherit from `ISO2022.Decoder`, which is actually rather inefficient. The concrete KR class uses a `DoubleByte.Decoder` that can now be created statically and used directly in the `decode` method - bypassing the `tmpDecoder` indirection and using tiny array+buffers which added quite a bit of overhead. So the performance gain here was significant, and is the explanation `ISO2022_KR` is now significantly ahead of the baseline on the `StringDecode` micro.

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

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