Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
rob.mckenna at oracle.com
Thu Jul 4 13:41:28 UTC 2013
I've just uploaded the latest changes which rebase the fix to the
current repo. (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) 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.
2) Should we simply ignore the flag on Windows or should we throw the
same error if its provided?
cc'ing Erik for a build review.
On 02/07/13 16:41, Alan Bateman wrote:
> On 23/12/2012 01:19, Rob McKenna wrote:
>> Hi Martin, thanks a lot for this.
>> I've renamed LINKFLAG to the more appropriate (and common) ARCHFLAG.
>> It seems to pop up all around our source but if build-dev know of a
>> better (or canonical) way of doing it I'll take it!
>> The BUILD_JEXEC differences don't show up in my webrev or hg diff,
>> but I see them in the jdk.patch generated by webrev. I have no idea
>> why this is. (I did use the JEXEC stuff as a template for the
>> JSPAWNHELPER code, but I don't recall altering the JEXEC stuff in any
>> way. It looks like its limited to indentation. Strange.)
>> W.r.t. useFork, I'll discuss this with Alan once he has a spare
>> minute. I believe he may have had some concerns, but I'll let you
>> know how that goes either way.
>> The only __APPLE__ should be to get the call to _NSGetEnviron().
>> Everything else should be bsd.
>> I've put a webrev at:
>> I hope this addresses the rest of your comments.
> Rob - this was great work but I don't think we brought it to a
> conclusion. Are you planning to re-base the patch and send out a new
More information about the core-libs-dev