Method to unmap MappedByteBuffer

[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.

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.


> Maybe safe unmapping can be done at a safepoint, but even that will
> break some JNI libraries because they assume that a direct byte buffer
> that is referenced will not be deallocated.  Perhaps this could be
> addressed by introducing a separate unmappable buffer type which does
> not count as a direct buffer from the JNI point of view.
>

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?

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...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190107/ed93cb9e/attachment.html>