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

Martin Buchholz martinrb at google.com
Fri Dec 18 19:59:09 UTC 2015

On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:

On 2015-12-15 18:25, Martin Buchholz wrote:

FILEOFFSETBITS 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 -DFILEOFFSETBITS=64, but that would be a big job. So traditionally the JDK has instead used the functions made available via LARGEFILE64SOURCE. 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 FILEOFFSETBITS=64 strategy, but it's probably a job for build-dev, not core-libs-dev. If I understand things correctly, then setting FILEOFFSETBITS=64 would mean two things: 1) Just pass this additional define to all C files being compiled (a build change) 2) Update all calls to file operating functions to make sure the proper 64-bit types are used (changes in source code). The change for 1) is a trivial one liner, while getting 2) correct is a serious undertaking in the source code.

If everyone is properly pairing up their function calls with proper types (i.e. using off_t consistently), then everything should Just Work.

Such a change must be done by the

component teams, not the build team.

I think this is an openjdk cultural problem - changes like this can and should be done by one person, with help from component teams where necessary. It's safer to add _FILE_OFFSET_BITS=64 everywhere at once (although hotspot and libraries can probably be cleanly separated) to avoid type size disagreement between translation units.

For bonus points, we can later change all of those *64 functions back to their standard equivalents.

With that said, I think it is a

reasonable change and I'll support it as much as I can. But as the division of labour is done here, it's not the work of the build team to go and make heavy modifications to the product source code.

More information about the build-dev mailing list