8202116: (fc) FileChannel.map should ensure mapped region is backed by disk space

[Alan Bateman]

On 24/04/2018 19:00, Colin McCabe wrote:
> :
>
> It seems like the idea behind this change is to move the pre-allocation to FileChannel#map, rather than having it in RandomAccessFile#setLength.  This is definitely better than having the preallocation in RandomAccessFile#setLength.
RandomAccessFile.setLength currently pre-allocates the space for the 
entire file. That was a mistake (in JDK 9 and 8uX) that only came to 
light in the last few days.

One option, which I don't like, but it's what we are discussing here as 
it's straight-forward, is pre-allocating the disk space for the mapped 
region (not the entire file). If you are memory mapping a sparse file 
then the space will be allocated as you write to the mapped byte buffer 
anyway (assuming you touch most of the region).

The other option that I'm playing with is treating BUS_ADDERR in the 
same way as BUS_OBJERR so that unsafe access handler is invoked and an 
exception thrown (as we have already when you truncate or remove the file).

> :
>
> Finally, I would argue that the FileChannel#map operation itself should not mutate the file.  In general, this operation is supposed to create a view of the file, not change the file.
Right although the region that you map may not be completely contained 
in the file so it has to extend the file. This is the only case that I'm 
aware of where the file size changes, the map method never changes the 
contents of the file.

>
> In general, it seems like what we really need is a way of translating I/O errors on an mmaped file to exceptions.  Most Java developers are not going to write signal handlers for SIGBUS.  But in order to have robust software when using mmap, they may want to handle I/O errors.  It would be really good if Java would make this possible.  Preallocation doesn't fix this problem, and it adds other problems which make mmap itself unappealing.
The long standing spec is to throw an unspecified exception when 
part/all of the mapped region becomes inaccessible. So I think it's 
covered already, it's just that there are case that weren't handled 
correctly in the original implementation. JDK-6415680 is an example that 
was fixed in JDK 10.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180425/4321255d/attachment-0001.html>