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

Ismael Juma mlists at juma.me.uk
Thu Apr 26 14:28:39 UTC 2018


Hmm, we may want to backport it to Java 8 too given that JDK8u161
unfortunately includes JDK-8168628.

Ismael

On Thu, Apr 26, 2018 at 7:25 AM, Ismael Juma <mlists at juma.me.uk> wrote:

> Seems like JDK-8202261 has been merged. Would a backport to Java 10 be
> considered? We would like to recommend Java 10 for Kafka users due to much
> faster TLS and CRC32C, but the increased disk usage (without JDK-8202261)
> could take users by surprise.
>
> Ismael
>
> On Thu, Apr 26, 2018 at 7:21 AM, Ismael Juma <mlists at juma.me.uk> wrote:
>
>> 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/cc899755/attachment.html>


More information about the nio-dev mailing list