Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
aph at redhat.com
Tue Sep 8 13:05:17 UTC 2015
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
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
>> 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.
More information about the core-libs-dev