RFR: 8324834: Use _LARGE_FILES on AIX

[Matthias Baesken]

On Mon, 29 Jan 2024 13:13:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the same spirit as [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt the AIX-specific code in hotspot so it uses the well-defined posix `<foo>` functions, instead of `<foo>64`. By setting the define _LARGE_FILES, this will make `<foo>` behave as `<foo>64`, just as _FILE_OFFSET_BITS=64 does on gcc. (Reference: https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files)
>> 
>> In theory, it should not even be necessary to set this, since we only compile for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But let's add the define anyway, for good measure. It shows at least that we have thought about the matter. :-)
>> 
>> I have not been able to test this on AIX. I hope someone with AIX access can take this for a spin.
>> 
>> The reason I'm doing this is for [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these bugs are fixed, there will be no more `<foo>64` function calls in the code base.
>
> Using the '_LARGE_FILES' should be okay, I checked this in a small example in the binary and it showed the the 64bit/large file function was used.

> Looks good from my end now. I leave the final approval to @MBaesken since he ran this through our testing I believe.

I put it into our build/test queue (so far had only a look at the change).
Unfortunately with going away from the <name>64  functions on AIX, it gets very intransparent. In case we lose the compile flag (or the compile flags gets filtered out/is not set for some compilation unit)  we silently fall back to "short files" support instead of "large files" support.

https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files
"It has the disadvantage of creating some ambiguity in the code because the size of the various data items cannot be determined from looking at the code"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1918611708