Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Alan Bateman Alan.Bateman at
Thu Jul 4 18:43:50 UTC 2013

On 04/07/2013 14:41, Rob McKenna wrote:
> Hi Alan,
> I've just uploaded the latest changes which rebase the fix to the 
> current repo.
Thank you (as you know I've been wanting us to move to posix_spawn on 
Mac and Solaris for a long time).

> (required post 8008118) I've also swapped out useFork for 
> jdk.lang.Process.launchMechanism. (it affords us the flexibility to 
> enable or disable other mechanisms on the various platforms at a later 
> date) 
The property name is good and given the potential for land mines then 
it's good to have a means to switch back. In time of course then maybe 
some of the old code can be removed. Personally I would go for the lower 
cases values. One idea is that as LaunchMechanism is platform specific 
then you could just get it to define the constants that it supports and 
then use valueOf on the property value to to do lookup.

> I have a couple of questions about this:
> 1) I'm thinking of including a unit test which will run through the 
> various permutations across each platform making sure we fail when 
> expected.
That would be good, it could call Martin's Basic test as that exercises 
this code very well.

> 2) Should we simply ignore the flag on Windows or should we throw the 
> same error if its provided?
I think it should be fine to ignore it, the property is meaningless on 
Windows at this time.

> cc'ing Erik for a build review.
I haven't done a detailed review yet but from a quick glance then you 
have cleaned up several things since the last round. Also, from what I 
can see then the trampoline (jspawnhelper) goes into the lib directory 
on Mac and lib/<arch> on Solaris which seems right (or at least 
consistent for those platforms).


More information about the core-libs-dev mailing list