During JDK-8324751, we have found some edge-case performance regressions.

They happen in cases where we have only aliasing, where we always end up multiversioning and taking the slow-path.

See the plots here:
https://github.com/openjdk/jdk/pull/24278#issuecomment-3213393035

-------------------------- INITIAL INVESTIGATION ------------------

I've done quite a bit of digging, and have not yet come to a definitive analysis. It is quite confusing, as the regression shows on all tested platforms, but not in an identical way.

I suspect that it has to do with code locality, i.e. that multiverisoning means we have more code, and so the code locality is not as good as before.

As soon as we have some non-aliasing cases mixed in, those benefit a lot from vectorization, and more than cancle out the regression. That is why we felt it was reasonable to integrate JDK-8324751. We did general performance testing and found no regressions, rather we found some speedups in some benchmarks.

You can find more in the PR here:
https://github.com/openjdk/jdk/pull/24278#issuecomment-3213393035

---------------- WORKAROUNDS -------------

Should you experience some performance regressions after JDK-8324751, you can always disable the aliasing runtime check with:
-XX:+UnlockDiagnosticVMOptions -XX:-UseAutoVectorizationSpeculativeAliasingChecks

You may even get away with disabling just multiversioning (would still allow runtime checks with predicate, i.e. if the runtime check never fails):
-XX:+UnlockDiagnosticVMOptions -XX:-LoopMultiversioning

An even bigger hammer would be disabling auto vectorization:
-XX:-UseSuperWord