Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

[Andrew Haley]

On 09/08/2015 09:58 AM, Paul Sandoz wrote:

> This is fundamentally about *integrity* of the runtime. It follows
> there are security implications, but it’s still fundamentally an
> integrity issue and guarding an unsafe operation with a Security
> Manager is unfortunately an insufficient solution.

That's an interesting distinction.  I'm not sure we're all that
consistent about it elsewhere.

But never mind that; how about this idea?  Create a
MappedByteBufferForwardingObject whose only job is to forward requests
to a MappedByteBuffer.  That MappedByteBuffer does not escape from the
forwarding object.  When the forwarding object is closed (or unmapped)
its MappedByteBuffer field is nulled.  The file can then be unmapped
because we know it is not reachable.  There would be some overhead for
the indirection, and that MappedByteBuffer field would have to be
volatile, so this would not be entirely free of cost.  It's very easy
to prototype this idea to see if it would be reasonably cheap.

However, I think that some cleverness in HotSpot could make that cost
go away.  For example, we could associate with every
MappedByteBufferForwardingObject a protection page in memory.  When
the forwarding object is unmapped that page is write-protected.  Every
access to the mapped file is preceded by a write to the page; there
don't have to be any memory fence instructions.  The protection page
would stay until the forwarding object was unmapped.

Andrew.