RFR: JDK-8272192 Shortcut String equality checks by checking equality of the value array [v2]

[Claes Redestad]

On Mon, 6 Sep 2021 06:45:07 GMT, q2q-2q2 <github.com+44376158+q2q-2q2 at openjdk.org> wrote:

>> Shortcut String equality checks by checking equality of the value array
>
> q2q-2q2 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8272192 Shortcut String equality checks by checking equality of the value array

David is right that many of these methods have VM intrinsics that'd have to be fixed to see much benefit of this. 

I can imagine some of these to be profitable in edge cases with string de-duplication enabled. Otherwise the backing arrays will typically never be shared and the identity test always be false (`""` is an exception to that rule that interestingly is unlikely to see any win from short-cutting). While the gain from a correct shortcut could be really large on a synthetic micro-benchmark, I still suspect the added test might be more costly in aggregate on the fabled "real application".

With compact strings it's easy to construct strings with different coders but the same `byte[]`, and string de-duplication could be implemented so that you end up sharing the same array between two semantically different strings (I suspect this is the case, but I might be wrong). This means there's a possible correctness issue in some places where you're shortcutting before checking either length or coder. 

All things considered I don't think this is worthwhile.

src/java.base/share/classes/java/lang/String.java line 1859:

> 1857:         byte v1[] = value;
> 1858:         byte v2[] = sb.getValue();
> 1859:         if (v1 == v2) {

This one is a bit tricky since it's only correct since we've asserted that `len == sb.length()`. It's unlikely to consistently give much of a boost, though, since `sb.getValue()` is very likely to have some unused padding at the end.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5370