The methods `load()`, `unload()`, `isLoaded()`, and `force()` in `MemorySegment` currently delegate to `ScopedMemoryAccess` through a set of `@Scoped` methods, after which the implementation calls into `java.nio.MappedMemoryUtils`. This means that, when a shared scope is closed during a call to one of these methods, an exception can be installed at any point during the execution of the util method.
The problem is that some parts of these methods are not able to handle such exceptions being installed. We've had some previous discussion about these methods not really needing to be `@Scoped` in the first place, but instead being able to rely on paired acquire/release of the session being accessed. This code is not as performance critical compared to a scoped memory access, since we're doing a native call any way. To avoid issues with exceptions being installed in surprising places, this patch switches the named methods to use acquire/release instead of being `@Scoped`. This changes the behavior of these methods slightly: they now keep the scope alive during the execution of the method. I've updated the doc, borrowing from existing text in the `Linked::downcallHandle` docs, to explain that a scope closure may now fail during the execution of one of these methods. Does this seem like the right tradeoff? --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - Missed one link - Fix links - Add keep-alive docs - Use acquire/release for memory mapped segment operations Changes: https://git.openjdk.org/jdk/pull/31918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=31918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8387723 Stats: 87 lines in 3 files changed: 31 ins; 39 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/31918.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/31918/head:pull/31918 PR: https://git.openjdk.org/jdk/pull/31918
