Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
David M. Lloyd
david.lloyd at redhat.com
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