RFR: JDK-8115868: 32-bit JVM failed to start from a large network filesystem

[Martin Buchholz]

Note that the semantics of stat and access may be subtly different,
and that there are many calls to stat in the JDK sources, and they may
all be broken on 32-bit systems.

I just wrote elsewhere:

_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 7:54 AM, Kumar Srinivasan
<kumar.x.srinivasan at oracle.com> wrote:
> Hello,
>
> Please review fix for: JDK-8115868
>
> The webrev is here:
> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/
>
> The background:
> The launcher uses stat(2) to check for the existence of a file,
> unfortunately
> on 32-bit system with large file systems causes the inode storage to
> overflow
> causing the syscall to return EOVERFLOW.
>
> Solution:
> * stat(2)  replaced with access(3), in most cases.
> * jbs is marked noreg-hard hard to replicate the problem
>
> Thanks
> Kumar
>
>
>
>
>