> When support for shared segment was added, we decided to disable support for 
> buffers derived from shared segment in certain async operations, as there's 
> currently no way to make sure that the memory won't be reclaimed while the IO 
> operation is still taking place.
> 
> After looking at the code, it seemed like the best place to put the 
> restriction would be sun.nio.ch.DirectBuffer::address() method, since this 
> method is used in a lot of places just before jumping into some piece of JNI 
> code.
> 
> While I still stand by that decision, the Netty team has discovered that this 
> decision also affected operations such as creating slices from byte buffers 
> derived from shared segment - this is caused by the fact that one direct 
> buffer constructor (the one for views and slices) is calling the dreaded 
> DirectBuffer::address method.
> 
> The fix is simple: just avoid the method call - which is very easy to do in 
> the case of the buffer constructor: in fact this method just returns the 
> value of the `address` field inside the `Buffer` class, so we can always cast 
> to `Buffer` and then access `address` field from there.

Maurizio Cimadamore has updated the pull request with a new target base due to 
a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into buffer_addr
 - Tweak direct buffer slice constructor not to use DirectBuffer::address

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

Changes: https://git.openjdk.java.net/jdk16/pull/110/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=110&range=01
  Stats: 11 lines in 2 files changed: 9 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/110.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/110/head:pull/110

PR: https://git.openjdk.java.net/jdk16/pull/110

Reply via email to