On 8 Sep 2015, at 11:30, Andrew Haley <a...@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.
