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
