|
From: Isenberg, H. <ise...@e-...> - 2009-02-19 11:19:54
|
As everyone who is launching external processes via Runtime.exec() or ProcessBuilder from a large Java-VM might have noticed, there are problems with that approach. During creation of the subprocess, the fork() operating system call is used which duplicates the current Java VM process which might be as large as, say 5GByte. The size of the subprocess is reduced shortly after, but for the time of the creation, twice of the current memory usage is needed or even n times the memory if you launch n processed at the same time. Sun describes the problem in the following articles and reports: "Minimizing Memory Usage for Creating Application Subprocesses" http://developers.sun.com/solaris/articles/subprocess/subprocess.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5049299 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6381152 They describe an approach to use the old fork() from a 2nd (and small) process and as with using the Java wrapper there is already that 2nd process available, it would be nice if the wrapper offers a Java method equivalent to ProcessBuilder() to launch a process and capture its stdout and stderr. To capture the stdout/stderr, PipedInputStream and PipedOutputStream using named pipes could be used. Named pipes are available on any Unix and also on Windows and can be easily and safely used on Java and C. Redirecting stdout/stderr in native C on the wrapper side can be done with the Posix functions pipe() and dup2(). Sample code: http://www.gidforums.com/t-3369.html . A kill-function to stop a runaway child process from Java without the need to shut down the Java backend should be included in the wrapper, too. That can use the posix function kill(). Wouldn't it be nice, if the wrapper included theses process features? How many wrapper users would need it? |