RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v8]

Chen Liang liach at openjdk.org
Sun Nov 16 16:17:06 UTC 2025


On Sun, 16 Nov 2025 14:50:39 GMT, Igor Rudenko <duke at openjdk.org> wrote:

>> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked:
>> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases 
>> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach
>
> Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust to TestMergeStoresMemorySegment.java requirements

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 535:

> 533:         }
> 534: 
> 535:         abstract String format(AbstractMemorySegmentImpl segment, long offset, long size, long length);

Even though this does look better, but abstract method in enum means extra classes, which become some extra burden for startup. If you can write this method to have a body like:

String formatString = switch (this) {
    case SLICE -> ...
    case ACCESS -> ...
};
return formatString.formatted(segment, size, offset, length);

This would be less costly.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 540:

> 538:     private static final class BoundsCheckHandler implements BiFunction<String, List<Number>, IndexOutOfBoundsException> {
> 539:         final AbstractMemorySegmentImpl segment;
> 540:         final BoundPolicy policy;

I recommend turning this into a private record. In addition, we should add a comment that we anticipate this record instance creation to be eliminated by escape analysis when segment access is compiled. I wonder if you have run benchmarks to verify this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2532054398
PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2532055796


More information about the core-libs-dev mailing list