RFR: 8357847: (ch) AsynchronousFileChannel implementations should support FFM Buffers [v7]

[Alan Bateman]

On Fri, 13 Jun 2025 17:58:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Acquire the scope of a direct buffer before it is used and release it after the task has finished with it, whether the task execution is immediate or pended.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8357912: Remove testViewsOfConfinedArenas sub-test of AsynchronousFileChannel/Basic.java

Marked as reviewed by alanb (Reviewer).

I did another pass over this and I think it's okay.

For SimpleAsynchronousFileChannelImpl + shared then it does 2 acquire/releases. The first acquire in the initiating thread and the second acquire in the pooled thread. Removing the acquire/release from the nested usage in IOUtil would be disruptive so I think what you have is okay because this isn't a widely used API and the implementation is begging to be replaced if more usage/interest were to happen in the future. Note that the isDirect checks in the change to this code aren't needed as acquireScope/releaseScope don't do anything when there isn't a session.

WindowsAsynchronousFileChannelImpl looks okay. The acquire is in the initiating thread and it releases if there isn't an I/O op pending. If pending then it gets released in the pooled-thread when the I/O op completes or fails.

The update to test is okay. Note that genBuffer doesn't release memory so maybe we should change this test to run othervm. Same thing for etc/MemorySegments.java as it leaks when testing allocations from the global arena. The imports of the DisabledXX annotations can be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/25531#pullrequestreview-2927826466
PR Comment: https://git.openjdk.org/jdk/pull/25531#issuecomment-2972481448