Method to unmap MappedByteBuffer

[Jonas Konrad]

 > What if the field is volatile? No synchronization would be needed.

There is still a race condition here. You would have to lock that field 
until your access operation is complete.

Overhead becomes an even larger issue if you make it volatile. You don't 
want every single buffer read to be a volatile read.

 > 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?

Direct buffers can be accessed directly in JNI, without an intermediate 
hotspot call. To get 0 from each unmapped access, the original page 
would still have to be mapped to something like PROT_NONE, with the 
issues mentioned previously.

- Jonas


On 2019-01-07 13:49, Luke Hutchison wrote:
> On Mon, Jan 7, 2019 at 5:38 AM Florian Weimer <fweimer at redhat.com 
> <mailto: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...)
>