On Mon, 6 Feb 2023 14:27:36 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>> 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. Nevermind, I had a flaw in my experiment and seems the first range check in a call like `Arrays.mismatch(encoded, 0, encoded.length, b, off, off+len);` should be eliminated. So perhaps you're seeing the cost of the second range check, which might be unavoidable to be safe (zip meta data could otherwise be doctored to try and perform out of bounds reads via intrinsified code) ------------- PR: https://git.openjdk.org/jdk/pull/12290
