-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b16
-
x86
-
solaris_10
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2150365 | 6u4 | Robert Mckenna | P2 | Resolved | Fixed | b02 |
FULL PRODUCT VERSION :
JRE 1.6.0-b105 (FCS)
ADDITIONAL OS VERSION INFORMATION :
Solaris 10 - 64-bit, SuSE 9, Debian
A DESCRIPTION OF THE PROBLEM :
We have a Java application with a large number of jar files which are included in the classpath. With JRE-1.6.0-b105, when an application is running which loads classes from any of these jar files, /proc/<pid>/fd shows that there is an open file descriptof for every jar file in the classpath. This is not the case with JRE-1.5.0_xx. We are having issues on Solaris 10 with "too many open files" when Java launches a subprocess running the SunStudio 11 cc compiler.
We are trying to upgrade to JRE 6 as a subsystem of MATLAB, but we can't get through our acceptance tests on Solaris with this problem.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run "java -classpath <path to 184 jar files with ":" separators> <class>"
where <class> can be found in one of the jar files in the classpath. Note that there is an open file descriptor for each jar file in /proc/<java-pid>/fd on either Solaris or Linux systems when running with jre-1.6.0-b105.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Behavior similar to jre-1.5.0_07, where only key files (e.g. rt.jar) are held open by the jre.
ACTUAL -
The Java program actually runs correctly, but the large number of open file descriptors seems to have a side effect when launching a "cc" sub-process from java.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
On Solaris, when the Java program launches a "cc" subprocess, it gets several "Too many open files" messages when processing the #include statements. On Solaris "cc" is a 32-bit application, even on a 64-bit system.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
We haven't found one yet. There is a possibility that this new behavior in JRE-1.6.0 is intentional as a performance enhancement, in which case it would be desirable to have an option (e.g. a -XX: option) to disable this behavior.
JRE 1.6.0-b105 (FCS)
ADDITIONAL OS VERSION INFORMATION :
Solaris 10 - 64-bit, SuSE 9, Debian
A DESCRIPTION OF THE PROBLEM :
We have a Java application with a large number of jar files which are included in the classpath. With JRE-1.6.0-b105, when an application is running which loads classes from any of these jar files, /proc/<pid>/fd shows that there is an open file descriptof for every jar file in the classpath. This is not the case with JRE-1.5.0_xx. We are having issues on Solaris 10 with "too many open files" when Java launches a subprocess running the SunStudio 11 cc compiler.
We are trying to upgrade to JRE 6 as a subsystem of MATLAB, but we can't get through our acceptance tests on Solaris with this problem.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run "java -classpath <path to 184 jar files with ":" separators> <class>"
where <class> can be found in one of the jar files in the classpath. Note that there is an open file descriptor for each jar file in /proc/<java-pid>/fd on either Solaris or Linux systems when running with jre-1.6.0-b105.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Behavior similar to jre-1.5.0_07, where only key files (e.g. rt.jar) are held open by the jre.
ACTUAL -
The Java program actually runs correctly, but the large number of open file descriptors seems to have a side effect when launching a "cc" sub-process from java.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
On Solaris, when the Java program launches a "cc" subprocess, it gets several "Too many open files" messages when processing the #include statements. On Solaris "cc" is a 32-bit application, even on a 64-bit system.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
We haven't found one yet. There is a possibility that this new behavior in JRE-1.6.0 is intentional as a performance enhancement, in which case it would be desirable to have an option (e.g. a -XX: option) to disable this behavior.
- backported by
-
JDK-2150365 Work around 32-bit Solaris stdio limit of 256 open files
-
- Resolved
-
- relates to
-
JDK-6280693 Mmap the whole jar files takes too much perceived footprint
-
- Resolved
-
-
JDK-6431278 Netbeans crash on 32 bit Solaris: need to call enable_extended_FILE_stdio() in VM initialisation
-
- Closed
-