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

[Martin Buchholz]

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
>
>