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

[Mike Hearn]

>
> 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.

Wait, or does it?

The primary place this matters is Windows. I must say that a
*significant* amount
of the time that I find or write Java that doesn't run across platforms
properly, it's due to differences between the platforms file locking
behaviours and in particular because Java does not open files with a
reasonable share mode on Windows.

The bug to change this is here:

https://bugs.openjdk.java.net/browse/JDK-6607535

The comment (from 2007) says that there's a new file IO API (presumably
this meant NIO) that uses the right share mode, but that it still doesn't
help for deleting a mapped file because Windows doesn't allow that.

But MSDN is a little contradictory:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366532(v=vs.85).aspx

These *calls to CloseHandle succeed even when there are file views that are
> still open*. However, leaving file views mapped causes memory leaks.


https://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx

The *DeleteFile* function fails if an application attempts to delete a file
> that has other handles open for normal I/O or as a memory-mapped file (
> *FILE_SHARE_DELETE* must have been specified when other handles were
> opened).


So it suggests that you CAN delete an mmapped buffer as long as the handles
were all opened correctly. If true then this would allow the following
implementation:

- Java always opens files with FILE_SHARE_DELETE. As any app that is not
expecting this behaviour is not portable anyway (would fail on UNIX), the
compatibility issues would hopefully not be too extreme.

- An attempt to close, delete or rename a file firstly remaps any mappings
of it to trigger access violations, then closes all underlying Win32
HANDLEs owned by the JVM, then returns. The actual unmap can be done
asynchronously as today once the GC comes along but it wouldn't matter
anymore because it's no longer stopping other file operations from working.