RFR: 8034944: (process) Improve subprocess handling on Solaris

[Peter Levart]

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