<i18n dev> RFR: 8261418: Reduce decoder creation overheads for sun.nio.cs.ext Charsets [v2]
redestad at openjdk.java.net
Tue Feb 9 21:14:56 UTC 2021
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:
>> 63: protected final byte maximumDesignatorLength = 4;
> 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.
More information about the i18n-dev