JDK-6627737 : VM should restore filedescriptor limit on ProcessBuilder.start()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u7,6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris,solaris_10
  • CPU: sparc
  • Submitted: 2007-11-08
  • Updated: 2010-09-01
  • Resolved: 2010-09-01
Related Reports
Relates :  
JDK-6670965 - (launcher) Runtime.exec inherits LD_LIBRARY_PATH modifications from java process
Description
We've had a complaint against SunStudio, 6624797, where it was discovered that
when an application is run under the IDE it's current/soft file descriptor
limit (usually 256) is equal to the max/hard limit (usually 65K).
This caused the application running under the IDE some grief.

A truss of the VM shows that it ups the current limit here:

=>[1] _setrlimit()
  [2] os::init_2()
  [3] Threads::create_vm(JavaVMInitArgs*,int*)
  [4] JNI_CreateJavaVM()
  [5] main()

IMO the VM should remember the original soft limit and restore it between when
it forks and execs.
---------------------------------------------------------
Incidentally to this I noticed that after a fork the VM will call
fcntl(FD_CLOEXEC) 65K times. Surely this is not an insubstantial time.
Cannot the VM runtime issue the fcntl(FD_CLOEXEC) right after each open/
accept etc?
Comments
EVALUATION We will not fix this. See comment section. If there's a measurable slowdown in startup for some application because of setting file limit to maximum, please file another bug with the details.
01-09-2010
WORK AROUND Another workaround is to launch Netbeans by passing "-XX:-MaxFDLimit" in Sun Studio launcher script.
15-02-2008
WORK AROUND See comments section for the workaround.
15-02-2008
EVALUATION See details from the comment section.
15-02-2008