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

[Paul Sandoz]

On 8 Sep 2015, at 11:30, Andrew Haley <aph at redhat.com> 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.
> 

True, in the sense that using Java reflection one could change the contents of an ArrayList but one still requires a reference, and that of course is even more unsafe to do on a String, which might be interned and where special optimisations are applied. Personally, i wish we could strengthen the integrity of the platform in such cases (without which it makes it much harder to apply certain optimisations).

I would argue the case of an unsafe unmap is more severe since there is no intent to break the integrity.


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

It’s not entirely clear to me if bulk operations would be safe under such circumstances. What if an unmap/remap concurrently occurs during an Unsafe.copyMemory when performing a Buffer.get/put with an array?


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

So basically the overhead would be a “plain" write and the indirection. Does that solve all cases Mark describes in the issue, specifically race conditions within the VM’s process?

Paul.