RFR: 8215017: Improve String::equals warmup characteristics

[Claes Redestad]

On 2019-04-11 18:06, Martin Buchholz wrote:
> I'm confused.
> This change seems to remove the one and only call to StringUTF16.equals, 
> making that dead code?
> Looking more closely at StringUTF16.equals and StringLatin1.equals, both 
> seem to boil down to equivalent """do the byte arrays contain the same 
> bytes?"""?
> Which suggests we can coalesce these two methods and have String.equals 
> simply check that the two coders and bytes are the same?
> Arrays.equals(byte[],byte[]) is also an intrinsic but has more checks.
> Hmmmm ... there's been performance work on ArraysSupport.mismatch.  
> Maybe we're not using it for Strings because we expect Strings to be short?
> I don't know if hotspot these days needs to keep intrinsics around for 
> library code that has been deleted.

Yes, this'd effectively kill off the need for StringUTF16.equals. I
don't think we need to hold on to the intrinsic, but would prefer
deferring that cleanup to a follow-up.

I noted earlier that Arrays.equals would work, but has quite different
peak and warmup behavior - some of it good, some of it bad (especially
during startup/warmup). As this is a performance-sensitive area I'd
prefer taking steps that are all-round improvements.

/Claes