RFR 4823133: RandomAccessFile.length() is not thread-safe (original) (raw)

Martin Buchholz martinrb at google.com
Tue Dec 15 17:25:52 UTC 2015

_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it affects interoperability between translation units. It would be good to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made available via _LARGEFILE64_SOURCE. But that is also a JDK-wide job now, because every call to plain stat in the source code is broken on 32-bit systems with 64-bit inodes, which are becoming more common.

I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job for build-dev, not core-libs-dev.

On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

Hi Yvom,

Minor comments: src/java.base/share/native/libjava/RandomAccessFile.c: - "length fail" might be clearer as "GetLength failed" src/java.base/unix/native/libjava/ioutilmd.c: - Please add a comment before the define of FILEOFFSETBITS to indicate where it is used and why it is there. - BTW, are there any unintended side effects? Perhaps a different issue but perhaps 64 bit offsets should be used everywhere src/java.base/windows/native/libjava/ioutilmd.c - Line 592: Using INVALIDHANDLEVALUE is better than -1 and is used elsewhere in the file BTW, Testing for invalid handle might be unnecessary since the call to GetFileSizeEx will fail if it is invalid, yielding the same result. Roger

On 12/10/2015 5:52 AM, vyom wrote:

Hi All, Please review my changes for below bug. Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/ <http://cr.openjdk.java.net/%7Evtewari/4823133/webrev0.0/> This change ensure that length() does not temporarily changes the file pointer and it will make sure that there is no race condition in case of multi thread uses. Thanks, Vyom

More information about the build-dev mailing list