On Mon, 6 Feb 2023 11:56:22 GMT, Eirik Bjorsnos <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/System.java line 2671:
>>
>>> 2669: if (false) {
>>> 2670: // Arrays.mismatch without the range checks (~5%
>>> faster micro getEntryHit)
>>> 2671: int aLength = encoded.length;
>>
>> Part of the difference you're seeing is due to knowing that you'll be
>> matching the entire length of the first array (`encoded, 0, encoded.length`).
>>
>> As an experiment I added `Arrays.mismatch(byte[], byte[], int, int)` to
>> mismatch the entire range of the first array argument vs the range of the
>> second and can spot an improvement in affected micros:
>>
>> Benchmark (size) Mode Cnt Score
>> Error Units
>> ArraysMismatch.Char.differentSubrangeMatches 90 avgt 10 12.165 ±
>> 0.074 ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo)
>> ArraysMismatch.Char.subrangeMatches 90 avgt 10 10.748 ±
>> 0.006 ns/op # mismatch(a, b, bFrom, bTo)
>>
>> This might be something we can solve in the JITs without having to add new
>> methods to `java.util.Arrays` to deal as efficiently as possible with the
>> case when we're matching against the entirety of one of the arrays.
>
> Interesting. Would be nice to solve this in the JIT!
>
> This disabled code got deleted in my last commit, but it seems like you have
> a good analysis so we can let it go now.
Right. I might have fumbled this experiment a bit, and perhaps your setup would
inline and then eliminate some of the known-in-range checks already.
Though we have intrinsified some of the `Preconditions.check*` methods in the
past to help improve range checks, but the `checkFromToIndex` method that would
be applicable here has not been intrinsified. It might be a reasonable path
forward to replace `Arrays.rangeCheck` with `Preconditions.checkFromToIndex`
and then look at intrinsifying that method to help eliminating or optimizing
some of the checks.
-------------
PR: https://git.openjdk.org/jdk/pull/12290
