On Tue, 9 Feb 2021 19:18:04 GMT, Naoto Sato <na...@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
