JDK-4343908 : jvm grows in memory and lwps until OutOfMemoryError after calling Runtime.exec()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.2.2,1.2.2_005
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2000-06-07
  • Updated: 2022-10-21
  • Resolved: 2001-05-15
Related Reports
Duplicate :  
JDK-4391042 - Received "not enough space" error when exec'ing a command
Relates :  
JDK-5049299 - (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Description
A Developer.com ISV provides a simple Java application which calls 
Runtime.getRuntime().exec() and forks new jvms.   Each jvm instantiates a fixed
number of work threads that eat CPU and stress test jvm and OS.  I/O associated
with each java.lang.Process is attached to java.io.InputStream/OutputStream
reference.  On other platforms such as Solaris 2.6, Linux, Win32, HPUX, 
the jvms appear stable and run continously.  However, on Solaris 7/8, the 
forked jvms exhibit growth (top/prstat) in resident and total memory used, 
plus rapid growth in associated lwps.  The growth continues unabated for 
several minutes until the jvms throw OutOfMemoryErrors at around 80MBs 
total memory size each and several hundred threads each.
Comments
EVALUATION y.s.ramakrishna@eng 2000-11-28: Please send the output from "java -version" to let us know the precise version of the VM that exhibits this behaviour. y.s.ramakrishna@eng 2001-04-17: A request for a test case and information on the VM version have yielded no response from the customer. Unless someone provides me with a test case that reproduces the problem, I will close this bug as incomplete within the next week. Thanks in advance for providing a test case. y.s.ramakrishna@eng 2001-05-15: We are unable to reproduce the problem using a test-case that consists of repeatedly doing a Runtime.exec and waiting for the process to complete then launching a new process. The number of lwp's stays steady, and the process image doesn't increase. Since we have not been able to obtain a reproduceable test case from customer, we are closing this bug. Please open a new bug with a test case when one becomes available. ###@###.### 2004-06-15: This is a response to the remark added in JDC on 2004/6/14 by zopilote2day. The problem you are seeing is that the parent process is likely leaking memory, and as a result the process image is bloating per each call. Once the process image size has exceeded a certain threshold, attempts to Runtime.exec() will run into the issue described in bug 5049299 which indicate that there is not enough free swap space on your machine to allow the fork-and-exec underlying the Runtime.exec() implementation. So there are really likely two issues here: (a) the memory leak per each call, for which we suggest you file a new bug with a test case that shows the problem, and including the JDK version information and the OS version information. (b) the lack of swap space on your machine which is compounded by bug 5049299.
18-06-2004
WORK AROUND On Solaris 7/8, I suspected significant differences in two-level threading model as compared to Solaris 2.6. Specifically, I suspected that there may be a problem with how resources such as process I/O streams are associated lwps which prevents garbage collection during runtime of native threads used to handle the I/O. As such, on Solaris 2.8, I switched the thread library by setting LD_LIBRARY_PATH to include first, /usr/lib/lwp, which provides a single level native thread library. This elminates the memory leak on Solaris 8.
18-06-2004