status of VM long loop optimizations - call for action

[Maurizio Cimadamore]

(resending since mailing lists were down yesterday - I apologize if this 
results in duplicates).

Hi,
few days ago some VM enhancements were integrated [1, 2], so it is time 
to take a look again at where we are.

I put together a branch which removes all workarounds (both for long 
loops and for alignment checks):

https://github.com/mcimadamore/jdk/tree/long_loop_workarounds_removal

I also ran memory access benchmarks before/after, to see what the 
difference is like - here's a visual report:

https://jmh.morethan.io/?gists=dfa7075db33f7e6a2690ac80a64aa252,7f894f48460a6a0c9891cbe3158b43a7

Overall, I think the numbers are solid. The branch w/o workarounds keep 
up with mainline in basically all cases but one (UnrolledAccess - this 
code pattern needs more work in the VM, but Roland Westrelin has 
identified a possible fix for it). In some cases (parallel tests) we see 
quite a big jump forward.

I think it's hard to say how these results will translate in real world 
- my gut feeling is that the simpler bound checking logic will almost 
invariably result in performance improvements with more complex code 
patterns, despite what synthetic benchmark might say (the current logic 
in mainline is fragile as it has to guard against integer overflow, 
which in turns sometimes kills BCE optimizations).

So I'd be inclined to integrate these changes in 18.

If you gave a project that works agaist the Java 18 API, it would be 
very helpful for us if you could try it on the above branch and report 
back. This will help us make a more informed decision.

Cheers
Maurizio

[1] - https://bugs.openjdk.java.net/browse/JDK-8276116
[2] - https://bugs.openjdk.java.net/browse/JDK-8277850