On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> 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 when testing with `-XX:-CompactStrings` > on M1 (up to -0.2ns/op per `String::equals`; neutral 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. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1927385726
