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.
