Missing trivial optimization in String equals

Claes Redestad claes.redestad at oracle.com
Tue Jan 23 00:13:49 UTC 2018


do you have an example application that is spending significant time
comparing the contents of such identical arrays and would benefit? I would
guess such comparisons are about twice as fast as typical ones due to
having to load half as much from memory. ;-)

If there's a valid optimization case, though, then it would only be
realizable when UseStringDeduplication is enabled. Thus it's crucial not
to regress all the other cases that won't benefit (Parallel, Serial, ...),
and as String::equals is often a very hot method then even a few added
instructions that only compare data we've already loaded into registers
might be too much. Or maybe not.

As String::equals is routinely replaced by a C2 intrinsic[1] that's
where we should look to optimize (not so much in the JDK library code).
I think it'd be straightforward to train that intrinsic to only emit the
test when the related feature is enabled. Maybe the kind folks over at
hotspot-compiler-dev at openjdk.java.net might be able to give some pointers.
If so I'd invite you to set up a set of experiments and see if this can
have a benefit.




On 2018-01-23 00:14, Martin Grajcar wrote:
> It looks like when testing equality of Strings, there's no test if the two
> arrays are actually the same object. This was impossible before Java 8u20
> (as no two strings used to share arrays), but it's well possible with
> -XX:+UseStringDeduplication.
> Maybe someone here cares...
> Regards,
> Martin.
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/String.java#l1014
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/StringLatin1.java#l89
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/777356696811/src/java.base/
> share/classes/java/lang/StringUTF16.java#l258

More information about the jdk-dev mailing list