Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the null check in our code (see Github) and the guardWithTest in the MethodHandle, although we never free duplicates. So a noop is better imho.
I like the Unsafe approach. To me both variants are fine. Uwe Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart <peter.lev...@gmail.com>: >Hi Chris, > > >On 12/10/2016 06:11 PM, Chris Hegarty wrote: >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > >Apart from the fact that Unsafe is (was?) reserved for low-level stuff, > >I think this approach is reasonable. Is the method in >jdk.internal.misc.Unsafe needed? You could add the method just to the >sun.misc.Unsafe (to keep internal Unsafe free from hacks) and export >the >two packages selectively to jdk.unsupported. > >> We could attempt to limit this to the direct buffer that "owns" the >> memory, i.e. not a duplicate or a slice, but I'm not sure it is worth >> it. > >What you have here *is* limited to direct ByteBuffer(s) that "own" the >memory. Derived buffer(s) (duplicated or sliced) do not have a Cleaner >instance (they have an 'attachment' to keep the 1st-level buffer >reachable while they are reachable). I would even make it more >unforgiving by throwing an IAE if the passed-in buffer didn't have a >Cleaner. In addition I would specify this behavior. For example: > >"Deallocates the underlying memory associated with given directBuffer >if >the buffer was obtained from either {@link ByteBuffer#allocateDirect} >or >{@link FileChannel#map} methods. In any other case (when the buffer is >not a direct buffer or was obtained by {@link ByteBuffer#duplicate() >duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct >buffer), the method throws {@code IllegalArgumentException}. > >Regards, Peter
