RFR: 8215017: Improve String::equals warmup characteristics

[John Rose]

On Dec 7, 2018, at 4:11 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> - Jim's proposal to use Arrays.equals is _interesting_: it improves
> peak performance on some inputs but regress it on others. I'll defer
> that to a future RFE as it needs a more thorough examination.
> 
> - what we can do is simplify to only use StringLatin1.equals. If I'm not
> completely mistaken these are all semantically neutral (and
> StringUTF16.equals effectively redundant). If I'm completely wrong here
> I'll welcome the learning opportunity. :-)

If they are semantically neutral then they belong in
the same place as the neutral intrinsics, which is
jdk.internal.util.ArraysSupport.  This in turn calls
the question of how the operation differs from
the existing mismatch intrinsic.

I'll go out on a limb here and say that the standard
ArraysSupport.mismatch intrinsic can probably be
tuned to cover string compares without hurting its
other customers.  Often such intrinsics are only
engineered for throughput on long inputs.
Later on we may find they can be additionally
tuned for other workloads, by adjusting the setup
logic, or (alternatively) they can be factored into
multiple entry points for specific use cases, with
complete sharing of assembly-level code except
for differing setup logic for the different use cases.
This sort of thing is the case with our arraycopy
intrinsics (used by the JIT) and may well also be
the case for array matching intrinsics.

I agree the above questions can be answered in
a separate investigation.

— John