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

Jorn Vernee jvernee at openjdk.org
Tue Nov 18 17:14:05 UTC 2025


On Tue, 18 Nov 2025 15:58:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Thank you for pointing this out, I believe we can move on with this solution if and only if the escape analysis eliminates instance creation. I'll run benchmarks you mentioned in order to check if it's so.
>
> The problem is that a JMH benchmark is typically not conclusive to evaluate impact of allocation. JMH benchmarks are small, so they typically run quite hot, and C2 can inline the entire benchmark code. This means escape analysis will routinely work in this context.
> 
> To make an example -- in an early version of the FFM API, we used not to have any static `MemorySegment::copy` method. The theory was that, instead of providing methods with explicit offset/length values, we could just address these use cases with a combination of `asSlice` + `copyFrom`. This seemed to be backed up by good JMH results.
> 
> But later on, some real world testing (with Apache Lucene) revealed that the cost for creating slices was visible, especially before the application was fully warmed up. This is kind of what I'm worried about here -- in the happy case I don't doubt that performance of this PR is (very) competitive (and I like the approach of your code changes!). But in cases where the code calling the bound check cannot be JIT-compiled (there might be many reasons for this), I wonder whether performance will remain competitive.
> 
> Unfortunately I don't know a good way to test this -- perhaps try to put a `DontInline ` in some of the JMH benchmarks and measure in that mode. @JornVernee  what do you think?

I think it's preferable to avoid the allocation, and I think we can. We can throw a pre-computed exception from `checkIndex`, and then catch that in checkBoundsAccess, and checkBoundsSlice, and re-throw a new exception with the right exception message.

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

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


More information about the core-libs-dev mailing list