Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
Paul Sandoz
paul.sandoz at oracle.com
Tue Sep 8 10:42:14 UTC 2015
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.
More information about the core-libs-dev
mailing list