Method to unmap MappedByteBuffer

[Luke Hutchison]

As far as I understood it, setting DELETE_ON_CLOSE is the way to make
actively mapped file deletion work with old versions of Windows, and yes,
requiring this flag to be set will be a problem for the normal usecase,
because many times you don't know whether a file will be deleted before it
is unmapped (eg. the caller of your library tries to delete the file after
calling one of your library routines, and GC has not yet unmapped the file).

That said, if File#deleteOnExit() was called on the file, maybe it would be
reasonable to set DELETE_ON_CLOSE, with the side effect that the file may
be deleted earlier than exit, when GC is called, if all references to the
file were dropped -- and his could affect some external program that uses
the file's disappearance to detect that the Java program has exited
cleanly. (Waiting for a file's disappearance is already not a reliable
method for detecting program exit, of course, since abnormal VM shutdown
can cause deleteOnExit() to fail to delete the file, or the program could
delete the file early, so maybe it is OK to change the timing of file
deletion for deleteOnExit() cases, and this would probably be an
improvement over the current situation.)

FILE_DISPOSITION_POSIX_SEMANTICS is the right way to do this on new
versions of Windows that does not require DELETE_ON_CLOSE, and that ensures
that later attempts to delete the file *through the normal deletion API*
hides the file and marks it for deletion once it is closed. This is the
correct fix for the file deletion lock issue with mmap moving forward, and
really should become part of JDK's MappedByteBuffer.

In fact setting POSIX file disposition on all files opened in Java on
Windows, so that all files have POSIX deletion semantics (not just those
mapped to ByteBuffers) would be immensely helpful, since this would make
Java more portable across operation systems, at least for future versions
of Windows 10. POSIX semantics seem to be expected more often than not by
Java programmers, and the file locking behavior on Windows is an Archilles'
heel that many projects have run into.

Neither of these mechanisms solve the other issue of concurrency and memory
security with forced unmapping, but it's a start.

Yes, the impact of early deletion should be investigated on the different
operating systems, to ensure behavior is reasonable and as cosistent as
possible across operating systems.




On Mon, Jan 14, 2019, 1:03 AM Alan Bateman <Alan.Bateman at oracle.com wrote:

> On 13/01/2019 17:02, Luke Hutchison wrote:
>
> :
>
> I asked about this on StackOverflow, and one of the responses indicated
> that POSIX file deletion semantics have been added to recent builds of
> Windows 10, via FILE_DISPOSITION_POSIX_SEMANTICS :
>
>
> https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddk/ns-ntddk-_file_disposition_information_ex
>
> This allows the file to be "deleted" while open by causing it to be hidden
> in the directory until it is closed (also allowing another file of the same
> name to be created in its place -- so the file is presumably also renamed).
>
> It looks like this is a solution to the file deletion part of this
> long-time problem, for new Windows builds at least. Can this be added to
> NIO for mmap'd files, if the Windows version supports it? (Actually it
> would be great to make POSIX semantics the default for all file operations
> in Java on Windows, but mmap is the most problematic case right now.)
>
> Thanks for this, it's something to check out.  That said, removing a file
> that is memory mapped has consequences if the file is removed or truncated
> (SIGBUS on Unix systems). That would need to be investigated to see what
> the impact would be. Also requiring DELETE_ON_CLOSE might be an issue too.
> FileChannel supports this option but it's usually for niche cases where you
> are using temporary files.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190114/94de27b4/attachment-0001.html>