On Tue, 8 Mar 2022 17:07:34 GMT, Claes Redestad <redes...@openjdk.org> wrote:
>>> Can we change the optimizer so that the strength reduction happens only >>> after all transformations have settled? Carelessly changing a >>> multiplication to a shift as today may hurt a lot of potential >>> optimisations. Thanks. >> >> Yes, it's troubling that making a constant non-foldable can lead the JIT >> down a path that ultimately pessimizes the end result (as observed here). If >> we could train the JIT to avoid this pitfall and get to the improvement >> observed in my experiment here without any changes to `String.java` then >> that'd be great. > >> @cl4es Yes, we would need to carefully measure the impact for small array >> sizes (similar to what we had to do when the array mismatch intrinsic was >> implemented and applied to array equals). My sense is to focus on the >> intrinsic and also look for potential opportunities like @merykitty points >> out, as that is where the larger impact is, although it is more work! > > Right, I'm not too thrilled about the prospect of moving ahead with the > de-constantification as an alternative patch here. It's such a crutch, but > it's also simple and has no obvious downsides as of right now. I think it was > a useful experiment to see where some of the gain observed in the unroll > might be coming from. The degradation on many smaller `Strings` in the > unrolled versions is a concern that I think might be a blocker, though. Short > Strings are excessively common as keys in hash maps et.c.. > > Feels like none of the alternatives seen here so far is really _it_. @cl4es that was indeed the issue leading to the crash. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7700
