> On 10 Dec 2016, at 19:47, Peter Levart <peter.lev...@gmail.com> wrote:
>
> 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.
Yes, possibly.
>> 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.
Understood, what I meant was throwing an exception if the given buffer
does not “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}.
Yes, but given a ByteBuffer it is not possible to determine if it “owns” the
memory, or not. So users of the API would have to have full knowledge of
the buffers they pass to it. Maybe this is ok?
-Chris.
