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

[Naoto Sato]

On Tue, 9 Feb 2021 21:10:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> 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.

OK. I don't think any more new ISO2022 charset would be added, so personally I still prefer the default impl in the ISO2022 itself, but I am ok with the code, as it improves the performance. Would you please add a comment explaining it?

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

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