Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

[David M. Lloyd]

On 09/08/2015 08:03 AM, Mike Hearn wrote:
>     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? ....... Then you do the real unmap when the buffer is GC'd
>     (maybe via Cleaner).
>
>
> Because the reason users are working around this is Windows, where they
> need the ability to do:
>
> buffer.unmap();
> file.delete();
>
> If the unmap is still asynchronous it doesn't solve the problem.

So Windows has no operation which can remap a previously mapped section 
of memory to something else? (say, just a block of non-access memory)

Note that such an operation has to be atomic with respect to all other 
operations which affect the address space of the process (or at least, 
which may randomly choose an address in memory at which to create new 
mappings), but not with respect to anything else really.  The point of 
the remapping is to continue to reserve the address space, without 
actually referencing what was there before (thus dodging file lock 
issues).  No physical or virtual memory need actually be reserved for 
such a mapping.

-- 
- DML