[foreign-memaccess+abi] RFR: Improve NIO channel support for buffer views over segments [v3]

[Maurizio Cimadamore]

On Thu, 22 Apr 2021 13:32:00 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Buffer.java line 828:
>> 
>>> 826:                 public Scope.Handle acquireScope(Buffer buffer, boolean async) {
>>> 827:                     var scope = buffer.scope();
>>> 828:                     if (scope == null || scope.isImplicit()) {
>> 
>> do you still need the null handling (both here and in IOUtil) ? We just return a singleton now for implicit scope, so I think you can make the code more regular w/o losing any performance.
>
> The null check is still needed - for "regular" buffers (that do not have a scope).
> 
> The `isImplicit` check can probably be removed. It is an unproven mirco-optimization to avoid the bloat of chaining unnecessary handles. It could be removed, and dropped altogether or pushed into the IOUtil code that does the chaining ( do not create a new Releaser for a handle that we've seen before, I assume handles can be compared by identity? )  Maybe I'll just drop this, and revisit later when benchmarking.

I see - I wonder if it would make sense to use global scope in these cases. But yes, this is probably best tackled in a separate patch.

>> src/java.base/share/classes/java/nio/Buffer.java line 831:
>> 
>>> 829:                         return null;
>>> 830:                     }
>>> 831:                     if (async && scope.ownerThread() != null) {
>> 
>> Crazy idea - are we sure we need this check? If user wants to really pass a confined buffer to an async IO, I belive a failure would still occur when the segment is accessed by a different thread - do you see reporting an error eagerly as something important? Will fibers change things so that e.g. we might be able to do more with a _single_ thread?
>
> I think that there is scope for tweaking this in the future. At the moment with the current structure, the Windows async socket channel implementation will access the memory behind the scope's/segment's back ( through the `long` address value that it retrieves ). It stores and reuses the "naked" address value from a thread other than that of the thread which initialed the I/O operation, all without invoking any memory access operations from Java. It's a non-trivial change to alter this, and not even clear if we should.

Ugh- ok, I see that different implementation might not necessarily trigger a scope check...

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

PR: https://git.openjdk.java.net/panama-foreign/pull/512