8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space
Alan Bateman
Alan.Bateman at oracle.com
Wed Apr 25 14:46:35 UTC 2018
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
More information about the nio-dev
mailing list