Method to unmap MappedByteBuffer

[Florian Weimer]

* Luke Hutchison:

> One of the problems with manually unmapping a DirectByteBuffer is that
> if you use the buffer after it is cleaned, you get a VM crash with "A
> fatal error has been detected by the Java Runtime Environment:
> EXCEPTION_ACCESS_VIOLATION".

That's not guaranteed at all.  If the address space is reused, you might
hit the C heap instead, a new mapped buffer, or something else entirely.

On Linux, you could replace the mapping with a PROT_NONE mapping, but
that would still count towards the VM area limit.

> With support for unmapping DirectByteBuffer instances, this should be
> softened to an exception (the whole VM should not crash!).

It is impossible to release the address space for reuse and ensure that
there is still a fault if the memory is accessed.

> On the security issue that Mark Reinhold brought up in his 2005 bug
> report, to do with leaking access to another user's mapped file
> contents if a subsequent buffer is mapped into the same address space:
> why not just have a field in the DirectByteBuffer that indicates
> whether the buffer has been closed? That requires one field value
> check per API call, which would slow down the use of DirectByteBuffer
> a bit (or maybe a lot, for code that makes a lot of one-byte reads
> from the DirectByteBuffer) -- but it would make the API 100% safe, and
> frankly safety should never be sacrificed for performance.

It's not safe without synchronization, and then the overhead could be
prohibitive.  Most of ByteBuffer is covered by compiler intrinsics
today, I think.

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.

Thanks,
Florian