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

[Martin Buchholz]

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:
>>
>> _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.
>
>
> If I understand things correctly, then setting _FILE_OFFSET_BITS=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.