On 03/21/2014 09:38 PM, Alan Bateman wrote:
On 21/03/2014 17:43, Rob McKenna wrote:
:
In a nutshell a new process reaper thread was spawned for every
Process created by the JDK. This fix runs these reaper threads in a
thread pool to save on thread creation when creating a lot of new
processes.
http://cr.openjdk.java.net/~robm/8034944/webrev.01/
Thanks Rob, it's good to get this change into the Solaris
implementation. I looked through Martin's original changes in
JDK-6944584 and the "side-port" as you've called it looks good.
-Alan.
Hi,
I wanted to take a look at sources to find out what is the purpose of
special "process reaper" threads that get started when child processes
are spawned from Java and see it if the API could be implemented without
them. I found out that there are two basic implementations. One for
Windows and one for UNIX OSes. The UNIX implementation has 4 variants
maintained in 4 more or less equal files that represent the same
UNIXProcess class. These 4 files have the UNIX OS variant encoded in the
extension so it's hard to maintain them with an IDE. Wouldn't it be
nicer to have one common UNIXProcess.java file for all 4 UNIX OS variants?
I took an exercise in re-factoring to see what it would take to merge
all 4 files into one. Here's what I came up with:
http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.01/
This is just a preview. It doesn't incorporate the fix for 8034944 yet
(when incorporated the code would get even simpler since there would be
less differences). It's still missing the runtime logic to resolve the
correct OS (currently only Linux), but it works on Linux (all 8 jtreg
tests for ProcessBuilder pass) and it should behave the same as original
code in every respect. I think this could be a starting point for making
code more maintainable. What do you think?
Regards, Peter
