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

David M. Lloyd david.lloyd at
Tue Sep 8 11:37:03 UTC 2015

On 09/08/2015 04:30 AM, Andrew Haley wrote:
> 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.

I think the real MappedByteBuffer would have to be cleaned up via 
PhantomReference in this case, and extra care would have to be taken to 
ensure that a premature GC does not occur (I guess that's the thrust of 
Paul Sandoz's reply).

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

If you're already doing this, why not skip the level of indirection and 
mprotect the entire mapped region to PROT_NONE when the user unmaps? 
The JVM could trap on that memory area and convert the signal to an 
UnmappedBufferException or some such.  Then you do the real unmap when 
the buffer is GC'd (maybe via Cleaner).  This is very akin to how file 
descriptors are cleaned up, AFAICT.


More information about the core-libs-dev mailing list