https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win.
I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win (up to -0.2ns/op per `String::equals` on M1; netural on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. ------------- Commit messages: - Fix and further cleanup RISC - Remove StringUTF16::equals Changes: https://git.openjdk.org/jdk/pull/16995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321468 Stats: 138 lines in 14 files changed: 0 ins; 113 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16995/head:pull/16995 PR: https://git.openjdk.org/jdk/pull/16995
