RFR 8214971 : Replace use of string.equals("") with isEmpty()

[Roger Riggs]

Hi,

I'm pretty sure, it is assumed that the JVM compiler will optimize this code
and produce an optimal result.  Lots of perf work went into the string 
size optimizations.

Also possible is to compare the value.length values before dispatching 
to Latin1 vs UTF16.
For unequal length strings, it can return false quickly. Comparing the 
value.length's
is the first operation in the respective Latin1/UTF16 static methods.  
(And they are HS intrinsics.)
This code has been tuned enough that any changes would need to start with
more performance evaluation.

$.02, Roger


On 12/6/18 9:56 PM, Stuart Marks wrote:
> On 12/6/18 2:42 PM, Claes Redestad wrote:
>> I filed this bug after seeing it in startup profiles, where isEmpty() 
>> avoids an instanceof and four(!) method calls, so getting rid of a 
>> few of these has a measurable impact on startup. It seemed prudent to 
>> just replace it all while we're at it.
>
> Interesting. The compact strings stuff saves a lot of space, but it 
> means that more setup work needs to be done before an actual equality 
> comparison can be done. Thus, equals("") has gotten quite a bit more 
> expensive relative to isEmpty() compared with the situation prior to 
> compact strings.
>
> Still, it seems like a method call could be saved here:
>
>         if (anObject instanceof String) {
>             String aString = (String)anObject;
>             if (coder() == aString.coder()) {
>                 return isLatin1() ? StringLatin1.equals(value, 
> aString.value)
>                                   : StringUTF16.equals(value, 
> aString.value);
>             }
>         }
>
> by saving the result of coder() in a local variable and then comparing 
> it directly to LATIN1. Is it worth it?
>
> (Note, this isn't relevant to the current review.)
>
> s'marks