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

[Ismael Juma]

Thanks Alan, the latest proposal sounds good to me.

On Wed, Apr 25, 2018 at 7:46 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180426/7df9e4d7/attachment.html>