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

[Martin Buchholz]

https://bugs.openjdk.java.net/browse/JDK-8000975
(process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux


On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz <martinrb at google.com>wrote:

> TL;DR - I support Peter's refactoring.
>
> It would indeed be nice to keep the very similar Unix implementations in
> one source file.  Once upon a time, such a unification was done with
> UNIXProcess_md.c, but there we had a C preprocessor to help.  Unifying the
> Solaris and Linux java sources as you have done was indeed a goal back in
> 2006.  I was saddened that the bsd/macosx ports added to the divergence.
>  Standing in the way is that few engineers have easy access to all the
> systems involved for testing, and it's very easy to introduce a subtle bug.
>
> We have also thought about whether having reaper threads is necessary.
>  The Unix rule is that child processes should be waited for, and some
> thread needs to do that.  There's no way to wait for a set of child pids,
> or to specify a "completion handler".  Well, you might be able to get the
> newish waitid() to do what you want, but it looks like it's not sufficient
> when java is running inside a process that might do independent subprocess
> creation outside of the JVM.
>
>
> On Sat, Mar 22, 2014 at 4:47 PM, Peter Levart <peter.levart at gmail.com>wrote:
>
>>
>> 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
>>
>>
>