RFR: 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address() [v7]

[Alan Bateman]

On Wed, 21 May 2025 13:42:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to use  `JavaNioAccess::getBufferAdress` rather than `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment instances can be used in classes that were not covered by https://github.com/openjdk/jdk/pull/25321
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms and configurations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year

src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 459:

> 457: 
> 458:             boolean pending = false;
> 459:             IOUtil.acquireScope(buf, true);

Would you mind checking the use of acquireScope in WindowsAsynchronousSocketChannelImpl? From a quick look I'm wondering why it doesn't call the 2-arg acquireScope with async=true.

test/jdk/java/nio/channels/AsynchronousFileChannel/Basic.java line 575:

> 573:             case 2 -> Arena.ofAuto().allocate(buf.length).asByteBuffer()
> 574:                     .put(buf)
> 575:                     .flip();

I wonder if we could extend this to test with a shared arena too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106767298
PR Review Comment: https://git.openjdk.org/jdk/pull/25324#discussion_r2106771546