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

[Kumar Srinivasan]

Hi  Bernd,

> Hello,
>
> I always like it when access() is used instead of stat() magic.
>
> I noticed that the new ProgramExists in java_md_common.c does not
> anymore reject directories (which are typically executable). Not sure
> it this matters or is intentional, it is a change in semantic.

Yes as the name suggests "ProgramExists", therefore that method should be
checking for the existence of the target file and whether it  is executable.

> Is there an exising typo in args.c#366 ("size i_s_ fine") which could
> be fixed in the patch as well?

I will refine that comment.

> I would simply remove the stat code from expandArgFile, the fallback
> code is only slow in the unlikely case of rejected large files so there
> is no need to attempt the stat() call. Would remove 10 lines.

I think it is correct, the way it is, because we could potentially have 
large argfiles
residing on slow file systems (smb, nfs etc.).

Thanks for the input.

Kumar

> Gruss
> Bernd
>
> Am Tue, 15 Dec 2015 10:36:08 -0800
> schrieb Henry Jen<henry.jen at oracle.com>:
>
>> Changes looks reasonable to me.
>>
>> Cheers,
>> Henry
>>
>>
>>> On 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
>>>
>>>
>>>
>>>
>>>