RFR: 8215017: Improve String::equals warmup characteristics

[Martin Buchholz]

Array copy and array compare seem like very similar optimization problems
and could even share some infrastructure.

On Thu, Apr 11, 2019 at 9:23 AM John Rose <john.r.rose at oracle.com> wrote:

> 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