On Mon, 4 Dec 2023 11:52:29 GMT, Francesco Nigro <[email protected]> wrote:
>> Yes, since the `coder` is checked first we know the bytes compared are >> either both latin1 or both UTF16 so there's no need for a UTF-16-aware >> char-by-char comparison here. In fact the `StringUTF16.equals` method looks >> completely unused. > > I can send a separate PR to remove it in case, unless we have any plans to > use it elsewhere `StringUTF16::equals` was used before https://bugs.openjdk.org/browse/JDK-8215017 - I don't remember exactly what performance verification I did back then. x86 intrinsics seem to emit the exact same asm, aarch64 does a little bit of extra optimization for the UTF16 case (avoids code and a branch for checking tailing byte, but only if the UTF16 string is 1-3 elements long). Perhaps we should double-check that JDK-8215017 didn't significantly regress some UTF16 equality checks before we rip out code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16933#discussion_r1413872054
