RFR (XS) 8060485: (str) contentEquals checks the String contents twice on mismatch

[Stanimir Simeonoff]

a

On Tue, Oct 14, 2014 at 10:55 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/10/2014 18:38, Aleksey Shipilev wrote:
>
>> Thanks guys!
>>
>> And of course, I managed to do two minor mistakes in a two-line change:
>> the indentation is a bit wrong, and cast to String is redundant. Here is
>> the updated webrev and the changeset (need a Sponsor!):
>>    http://cr.openjdk.java.net/~shade/8060485/webrev.01/
>>    http://cr.openjdk.java.net/~shade/8060485/8060485.changeset
>>
>> -Aleksey.
>>
>>

>  Updated version looks okay. I wonder how common it might be to call this
> method with String vs. a StringBuilder, just wondering if it should check
> for a String first (although the type check should be really quick and
> probably wouldn't make a difference).
>
> I was wondering the exactly same but usually allowing CharSequence in the
code means "likely no String", so while there is no statistical evidence it
seems reasonable.

Another minor issue is the legacy contentEquals(StringBuffer sb) that can
call directly synchronized(sb){nonSyncContentEquals(sb);} but C2 should be
able to inline it pretty good just in case.

Stanimir