SPUG: reducing memory footprint of forked children?
Jim Flanagan
jimfl at colltech.com
Wed Feb 13 11:03:03 CST 2002
--On Wednesday, February 13, 2002 8:28 AM -0800 Benjamin Franks
<benjamin at dzhan.com> wrote:
> In programs where a parent forks off a number of child processes, is
> there a way to reduce the memory footprint of the child processes?
> If I understand correctly, the child inherits a duplicate copy of
> the parents variables, etc.. Can the child explicitly undefine
> parent variables the child doesn't need? What about unecessary
> modules the parent needs that the child doesn't---can modules be
> unloaded in the child? Even if these techniques did reduce the
> memory consumption of the child, would it be visible on a program
> like top (or something similar) or would the memory be unused but
> held until child death? Is there a way to force a
> reallocation of unused memory while the child is running, or is that
> more of an OS issue?
In many UNIX-shaped operating systems, the effects of doing a fork()
are mitigated in several ways. The most common is shared objects. Once
they're loaded, there will only be one copy of them in memory. Much of
the perl executable is going to be made up of shared object code, and
many of the more sophisticated modules will also be sharable code.
On some systems, such as Linux, a call to fork() actually
generates very little overhead, because it is implemented using
copy-on-write pages. So the two processes are not copies of each other,
they are identical except for their process id, parent process id. All
that is created is the kernel datastructure to keep track of the new
process. Only if you change the data will a new page have to be copied
from the old one and the data modified in that new page. Of course that
means if you change one variable in the child, you have to copy an entire
page in memory. Still better than copying all the non-shared pages.
In this case, actually undef-ing variables will do more harm than good!
Other Unices (Solaris, is an example) provide the vfork() system call
which does essentiallly the same thing (where as fork() is left as a
heavyweight clod-stomper). Your version of perl may or may not be
compiled to use vfork() instead of fork(). You can tell by doing a
`perl -V:usevfork'.
(You will annoy your system administrators by asking them to re-build
perl to use vfork(), and while they're at it didn't they notice that emacs
had a new point release last night? Offer to buy them more memory
instead.)
On a non-Unix OS, your milage may vary wildly. Sometimes fork() is
emulated using threads (so you only get the overhead of an additional
thread)
--
Jim Flanagan
jimfl at colltech.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org
More information about the spug-list
mailing list