On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty <che...@openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:
>> 
>>> 464:     }
>>> 465: 
>>> 466:     private static final JavaNioAccess NIO_ACCESS = 
>>> SharedSecrets.getJavaNioAccess();
>> 
>> It might be cleaner to move to acquire/release methods to their own 
>> supporting class as it's not really IOUtil.
>
> I went back and forth on this a number of times already. I think where we 
> landed is a reasonable place, given the current shape of the code.
> 
> Scope is a private property of Buffer, and as such should be consulted 
> anywhere where a buffer's address is being accessed. In fact, a prior 
> prototype would not allow access to the underlying address value without the 
> caller passing a valid handle for the buffer view's scope. It's hard to find 
> the sweet-spot here between code reuse and safety, but the high-order bit is 
> that the code accessing the address is auditable and testable to avoid 
> accessing memory unsafely. Maybe there is a better alternative implementation 
> code structure (at the cost of some duplication), but it is not obvious to me 
> what that is (and I have given it some thought). Suggestions welcome.
> 
> Note, there is a little more follow-on work to be done in this area, if we 
> are to expand support to other non-TCP channel implementations. Maybe 
> investigation into possible code refactorings could be done as part of that?

Can you create a follow-on issue to re-visit the changes to IOUtil? The changes 
in this area that are in this PR will need to re-worked so that it more cleanly 
separate the synchronous and asynchronous usages.

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

PR: https://git.openjdk.java.net/jdk/pull/3699

Reply via email to