JDK 9 RFR of 8168628: (ch) JVM Crash in : ~StubRoutines::jshort_disjoint_arraycopy

Brian Burkhalter brian.burkhalter at oracle.com
Tue Dec 6 16:26:57 UTC 2016

On Dec 6, 2016, at 6:01 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Looking at FileDispatcherImpl.allocate0 then I assume the fstat64 to check the file size isn't needed - we should only be calling allocate0 when extending the file.

I think that is what it is doing, no?
 193     jint fd = fdval(env, fdo);
 194 #if defined(__linux__)
 195     /*
 196      * On Linux, if the file size is being increased, then ftruncate64()
 197      * will modify the metadata value of the size without actually allocating
 198      * any blocks which can cause a SIGBUS error if the file is subsequently
 199      * memory-mapped.
 200      */
 201     struct stat64 fbuf;
 203     if (fstat64(fd, &fbuf) == 0 && size > fbuf.st_blocks*512) {
 204         return handle(env,
 205                       fallocate64(fd, 0, 0, size),
 206                       "Allocation failed");
 207     }
 208 #endif
 209     return handle(env,
 210                   ftruncate64(fd, size),
 211                   "Truncation failed");

> The updated synchronized block in FileChannelImpl.map looks okay although not pretty to have it include the GC+ retry. It would be an unlucky day if extend the file and then mmap fails.

Agreed, but I don’t immediately see another way to do this.

Is the patch OK as-is or do you think further updates are needed?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161206/4d268a64/attachment.html>

More information about the nio-dev mailing list