This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: posix_spawn's usage of fork versus vfork


 Mike Axiak wrote:
> Hello,
>
> I'm not sure if this is the list to ask about this, but I figure
> someone might be able to point me in the right direction :-).
> I've recently hit an issue in a Java environment in linux wherein
> executing small processes tries to allocate too much virtual memory
> [1].
> The issue really comes down to competing architectural designs, but I
> have to make the project I'm working on work, and have to come up with
> a solution.
>
> The issue I'm seeing is this: as you know, there are two calls to fork
> a process: vfork() and fork(). Fork will duplicate the virtual memory
> space and perform a copy-on-write in order to maintain program space
> in the child process. This is a problem for applications with large
> monolithic address spaces, as the duplication of virtual memory space
> can easily fail in normal conditions (imagine a single process with a
> 4GB heap trying to run a 10KB shell program). From what I can tell,
> vfork does not do any of this, and will merely move execution to
> another loaded program. Now, if I want to run an external program
> performing a fork/pipe redirect/exec, I have to have some way of
> passing the fd redirect information to the child process.
How is it failing? There's a small penalty on marking all the process pages
as copy-on-write, then unmarking, but I don't see what would make a fork()
to fail but a vfork() to succeed there (considering).
Note that bug was marked as affecting Solaris but not Linux:
> Solaris reserves swap space conservatively, so when an X-megabyte process
> forks the kernel attempts to reserve an additional X MB of swap space just in
> case the child actually does touch all those pages, thereby making private
> copies, and then later needs to swap them out.  (Linux doesn't do this, so
> this bug will not be reproducible on a Linux system.)

Maybe you are running with overcommit disabled?
Also note, that bug 5049299 is marked as fixed.
If I had to work around it, I would probably create a zygote process at
the beginning
and then route all new process requests through it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]