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

[Andrew Haley]

On 09/08/2015 11:42 AM, Paul Sandoz wrote:
> 
> On 8 Sep 2015, at 11:30, Andrew Haley <aph at redhat.com> wrote:

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

I don't think you'd actually need to unmap anything until a safepoint.
I don't think that the speed of unmapping is critical as long as it
happens "soon".

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

As far as I can see, yes.

Andrew.