Linux and GC

[Chris Bitmead]

Mike McDonald wrote:

>   Isn't the problem of using multiple cpus for GC one of balance? One
> would like the collector threads to have enough resources so that they
> stay ahead of the mutators. But you don't want to dedicate CPUs to
> collector threads because then you waste those resources when not
> collecting. 

I don't see this as such a big problem. Just allocate a number of
threads to GC based on how much collecting you want done. When
there is plenty of free space, turn off all the threads. When
things get desperate, allocate 2 or 3 threads to GC.

> Then there's the problems with adding the garbage back on
> the free list. You'll need some kind of lock for that. MP locks tend
> to be "expensive". Do you incrementally add things to the free list or
> do it all at the end? Incrementally has the advantage of reusing the
> space as quickly as possible. The disadvantage is the constant locking
> and unlocking of the free list lock.

I don't see this as an issue. Have 2 free lists. The GC adds to
one, and the process takes away from the other until it runs out.
Then they are swapped. Only when the process runs out of space
does it need to waste a couple of extra micro seconds swapping
free lists.

> Doing it at the end of a gc pass
> means I only have one short access period to the lock. Disadvantage is
> the mutators have to wait longer for the space to be reclaimed.
> Depending on the allocation profile of your app, it seems either could
> be the better way to go.

-- 
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au