Re: Copy-on-write friendly garbage collector

Hongli Lai wrote:
> Daniel Berger wrote:
>> I recommend against this. Most people are simply not going to know
>> when they should invoke it and when they shouldn't. It's an
>> implementation detail that should be hidden from the user IMHO.
>> Besides, it really worth splitting it out like this over a 5% speed
>> hit? Or am I missing some other implementation detail?
> 
> Apparently people care about even a 5% speed hit, or we wouldn't still 
> be discussing this.

I can certainly see a need for this as an _option_, even if it does cost 5%.

IIUC, it would make a difference if your main process (say, an in-memory 
database, or a large simulation) constructed a big set of objects. Then 
you want to fork to generate some graphs from the simulation or perform 
a search of the database. Currently, the best solution is GC.disable (in 
the fork), but that's not good if the fork needs to live a while (and 
the parent will eventually GC anyway).

The 5% cost is much less than the cost of thrashing because all these 
forks can't share memory. If the simulation or database process doesn't 
need to GC much, the 5% is negligible.

OTOH, most programs probably don't benefit, so shouldn't pay the 5%.

Thanks for your work on cowruby, Hongli.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407