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;
202
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?
Thanks,
Brian
-------------- 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