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.

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

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259636
  Stats: 19 lines in 2 files changed: 18 ins; 0 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