> 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