On Dec 7, 2018, at 4:11 PM, Claes Redestad <claes.redestad@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