From: Daniel DeLorme <dan-ml@...42.com>
Date: 2007-03-13T20:53:40+09:00
Subject: Re: You thoughts/philosphies on manual garbage collection

Joel VanderWerf wrote:
> 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. If the parent has a large heap, and the child does a GC, 
>  all those pages are copied into the child's address space. Memory usage 
> will scale badly as the number of child processes grows. (Perhaps you 
> factor your process into one child for each of the hundreds of files?)
> 
> It can be a good idea to GC.disable in the child, in some cases:
> 
> - parent has large heap, and
> 
> - child lifespan and allocation rate are such that is does not need to GC
> 
> Some benchmarks:
> 
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/186561

I looked for some extra information on this topic and found:
http://blog.beaver.net/2005/03/ruby_gc_and_copyonwrite.html

That's pretty disheartening news to me. I had plans to make a fcgi-like 
process manager that would take advantage of copy-on-write to reduce the 
memory footprint of a webapp by pre-loading all libraries in the parent 
process. But if ruby's GC renders COW useless... there's not much point 
anymore.

Are there any plans to optimize ruby to make it fork-friendly?

Daniel