On Mar 11, 2007, at 3:26 PM, Joel VanderWerf wrote:

> ara.t.howard / noaa.gov wrote:
>> if you can fork - that's the best - then you just let each child's  
>> death clean
>> up that sub-segment of work's memory.
>
> One caution: mark-and-sweep GC and fork don't always play well  
> together, in terms of sharing memory pages. The mark algorithm  
> needs to touch all live objects in the heap. The child inherits the  
> parent's heap, with copy on write.

I think you are describing a different situation than the OP and Ara.

If you've got hundreds of files to process and the processing is  
sufficiently
complex to justify forking for each file then the parent just  
iterates over
the file list forking and waiting for each child to process each  
file.  The
parent's address space won't have all the stale objects generated by  
the child's
processing so each new child starts with a reasonable memory footprint.

One fork per file is the easiest to program but if that is  
problematic for
some reason you could batch things up pretty easily.


Gary Wright