Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
Hi Rob, Martin, et.al. I've prototyped (for 9) a thread reaper[1] that uses a single thread to wait for exiting processes and calling back to the process with the exit status. the interesting part is getting the exit status back to the Process that needs it It needs more testing and hardening. I had not considered using a signal handler for SIGCHLD but that's an option, though we need to be very careful about thread usage. Roger p.s. comments on the single thread reaper appreciated (in a new thread) [1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/ On 3/24/2014 12:38 AM, Rob McKenna wrote: Hi folks, Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper thread arrangement in 9 at the moment. On another note, I too support the merging of those files. I didn't think there was much appetite for it at the time so I must admit this fell down my todo list. Looking at this bug did remind me that its something worth trying though. As per Alan's mail, I'm going to tackle it separately if you folks don't mind. I'll have a look at Peter's changes (thanks Peter!) as soon as I can and see about getting them in. -Rob On 23/03/14 22:30, Martin Buchholz wrote: On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz marti...@google.com mailto:marti...@google.com wrote: 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. Actually, I take it back. With sufficient work, it looks like you can get SIGCHLD to give you pid information in siginfo_t si_pid, and that can be used to trigger the reaping. It looks like waitpid is async-signal-safe, so we can call it from our signal handler. While we're at it we can fix SIGCHLD handling to do signal chaining, as with other signals.
Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
On 22/03/2014 23:47, Peter Levart wrote: : I took an exercise in re-factoring to see what it would take to merge all 4 files into one. There is a long standing bug proposing that the implementations be merged (Martin will remember some of the history on this). I would prefer that we keep this separate to avoid complicating Rob's side port (Rob's side port is for 7u and 8u, not 9). -Alan
Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
Hi folks, Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper thread arrangement in 9 at the moment. On another note, I too support the merging of those files. I didn't think there was much appetite for it at the time so I must admit this fell down my todo list. Looking at this bug did remind me that its something worth trying though. As per Alan's mail, I'm going to tackle it separately if you folks don't mind. I'll have a look at Peter's changes (thanks Peter!) as soon as I can and see about getting them in. -Rob On 23/03/14 22:30, Martin Buchholz wrote: On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz marti...@google.com mailto:marti...@google.com wrote: 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. Actually, I take it back. With sufficient work, it looks like you can get SIGCHLD to give you pid information in siginfo_t si_pid, and that can be used to trigger the reaping. It looks like waitpid is async-signal-safe, so we can call it from our signal handler. While we're at it we can fix SIGCHLD handling to do signal chaining, as with other signals.
Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
..just realised I had an out of date webrev up there, I've just updated in place in case anyone is looking at it. -Rob On 21/03/14 17:43, Rob McKenna wrote: Hi folks, I'd like to push this change into JDK8 7. There is other work going on in 9 which will supersede this fix so there is likely no point in pushing to that release. This is backport of the threadpool specific changes from https://bugs.openjdk.java.net/browse/JDK-6944584 along with some cosmetic changes in order to keep the code somewhat similar. 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/ -Rob
Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
Just when I thought I beat you to it Martin. :) On 21/03/14 18:32, Martin Buchholz wrote: OK, latest webrev looks much smaller, and appears to have only a port of changes from my changes to Linux from a few years ago. (please confirm). If so, Looks Good To Me. Yup, everything that is in this webrev comes from your port. (though conversely not everything from your fix was ported over) And yep, this is a sideport. While looking at this, I think bumping the thread stack size by a factor of 2 (32k = 64k) seems timely, since native stack requirements (native sizes, alignments and overhead) seem to increase over time. But I'd put that into a separate change. Thanks for the comment, I'll take an AI. -Rob On Fri, Mar 21, 2014 at 11:23 AM, Rob McKenna rob.mcke...@oracle.com mailto:rob.mcke...@oracle.com wrote: ..just realised I had an out of date webrev up there, I've just updated in place in case anyone is looking at it. -Rob On 21/03/14 17:43, Rob McKenna wrote: Hi folks, I'd like to push this change into JDK8 7. There is other work going on in 9 which will supersede this fix so there is likely no point in pushing to that release. This is backport of the threadpool specific changes from https://bugs.openjdk.java.net/browse/JDK-6944584 along with some cosmetic changes in order to keep the code somewhat similar. 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/ http://cr.openjdk.java.net/%7Erobm/8034944/webrev.01/ -Rob
Re: RFR: 8034944: (process) Improve subprocess handling on Solaris
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.
