Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Alan Bateman
Alan.Bateman at oracle.com
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.
>
> http://cr.openjdk.java.net/~robm/5049299/webrev.04/
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).
-Alan.
More information about the core-libs-dev
mailing list