Following the correctness fix in JDK-8266371, a number of performance regressions have been observed throughout the memory access benchmarks. All the regression have some characteristics in common:

* they disappear when tiered compilation is enabled
* they disappear when small segment optimization is disabled
* they exhibit as the benchmark starting off fast, but then suddenly slowing down by 4x or so (probably the effect of a bad recompilation).

The most affected benchmark is UnrolledAccess.handle_loop which is 5x slower than UnrolledAccess.handle_loop_static.

The fix for 8269230 should have helped, but it didn't fix all cases.

Until we can remove small segment optimizations, the more reliable fix is to use `<=` instead of `<` and `>=` instead of `>` inside AbstractMemorySegment::checkBounds:

diff --git a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
index de95a2c5d87..ecb918d778e 100644
--- a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
+++ b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
@@ -398,8 +398,8 @@ public abstract non-sealed class AbstractMemorySegmentImpl extends MemorySegment
 
     private void checkBounds(long offset, long length) {
         if (isSmall() &&
- offset < Integer.MAX_VALUE && length < Integer.MAX_VALUE &&
- offset > Integer.MIN_VALUE && length > Integer.MIN_VALUE) {
+ offset <= Integer.MAX_VALUE && length <= Integer.MAX_VALUE &&
+ offset >= Integer.MIN_VALUE && length >= Integer.MIN_VALUE) {
             checkBoundsSmall((int)offset, (int)length);
         } else {
             if (length < 0 ||