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