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

On 12/16/2015 11:01 AM, Martin Buchholz wrote: On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: 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

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

This is surely progress, but no one seems to own the problem of fixing all the stat calls in the JDK. Instead of failing at startup, we may get a more obscure failure later at runtime, which not everyone will think is progress. On Thu, Dec 17, 2015 at 5:32 AM, Kumar Srinivasan

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

On Tue, Dec 15, 2015 at 2:12 PM, Bernd Eckenfels wrote: > 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

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

On 12/16/2015 1:24 AM, Mikael Gerdin wrote: On 2015-12-16 09:24, Mikael Gerdin wrote: Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to

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

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

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

On 2015-12-16 09:24, Mikael Gerdin wrote: Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to comment on the actual code changes I don't

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

Hi Kumar, On 2015-12-15 16:54, Kumar Srinivasan wrote: Hello, Please review fix for: JDK-8115868 The webrev is here: http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ Since I don't feel qualified to comment on the actual code changes I don't consider this a code review but I looked at

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

OK, now doing an actual review ... this does look like a clear improvement!

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

Changes looks reasonable to me. Cheers, Henry > On Dec 15, 2015, at 7:54 AM, Kumar Srinivasan > wrote: > > Hello, > > Please review fix for: JDK-8115868 > > The webrev is here: > http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/ > > The background: > The

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

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

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

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. Is there an exising typo

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

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