8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space

[Alan Bateman]

Take 2 ...

As we've been discussing in the other threads, the changes in 
JDK-8168628 in JDK 9 and 8uX were a mistake that we need to fix.

I've re-examined the error logs from the original bug report, also fresh 
core files using Brian's test, and I'm now confident the underlying 
issue is that the bulk transfer operations (based on unsafe copyMemory) 
aren't guarded, hence the SIGBUS handler doesn't translate the fault 
into an exception. The single element put/get use unsafe operations with 
memory guards so they will throw an exception when the underlying file 
is truncated, removed, or there isn't disk space available (usually 
BUS_OBJERR or BUS_ADRERR). David Holmes confirmed with a link to 
JDK-8191278 where the issue with Unsafe.copyMemory is tracked.

In the mean-time, we can partly workaround the original issue with the 
changes that we discussed via JDK-8202116. I'm not comfortable with that 
change, even on ext4 where fallocate just allocates the meta data to 
support the additional space. While it addresses the original issue, it 
doesn't help with bulk transfers faulting for other reasons.

So I've decided to close JDK-8202116 and instead use a subset of that 
patch to revert JDK-8168628. In summary, this reverts 
RandomAccessFile.setLength and FileChannel.map so that they don't 
preallocate space. The rest is just cleanup.

http://cr.openjdk.java.net/~alanb/8202261/webrev/index.html

-Alan