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

[Ismael Juma]

Thanks Alan, the latest proposal sounds good to me.

Ismael

On Wed, 25 Apr 2018, 07:47 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/9050ce52/attachment-0001.html>