SPUG: reducing memory footprint of forked children?

[Jim Flanagan]

--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