Method to unmap MappedByteBuffer

[Florian Weimer]

* Luke Hutchison:

> On Mon, Jan 7, 2019 at 5:38 AM Florian Weimer <fweimer at redhat.com> wrote:
>
>  > why not just have a field in the DirectByteBuffer that indicates
>  > whether the buffer has been closed?
>
>  It's not safe without synchronization, and then the overhead could be
>  prohibitive.  Most of ByteBuffer is covered by compiler intrinsics
>  today, I think.
>
> What if the field is volatile? No synchronization would be needed.

There's still a race.  And volatile still needs synchronization.
(Even the compiler barrier is costly.)

> If you try to close a ByteBuffer while one of its methods is running
> in another thread, you get to keep both pieces (i.e. the caller would
> be responsible for synchronization if this is a possibility). This is
> no different from any other file access API.

My understanding is that FileInputStream etc. properly guard against
concurrent close, by interposing a fake descriptor via dup2 and other
tricks.

> Not sure I understand the implication to JNI libraries. But after
> unmapping, couldn't MappedByteBuffer simply return zero byte values
> from any read calls, without actually being mapped to something?

No, if the address space is unused, it will fault.  If it is reused,
anything an happen (especially for writes, but stray reads to device
could have unpredictable effects as well).

> What about my last suggestion, of physically overwriting the class
> pointer within a MappedByteBuffer object with another class definition
> whose methods throw an exception?  (It is hacky and unorthodox, but it
> should work, I think...)

It still needs synchronization.  But in compiled code, the class pointer
is not used for calling (effectively final) methods anyway.

Thanks,
Florian