RFR: 8034944: (process) Improve subprocess handling on Solaris
martinrb at google.com
Sun Mar 23 09:39:41 UTC 2014
(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.
>> 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.
>> 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:
>> 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
More information about the core-libs-dev