Linux and GC

Kragen kragen@pobox.com
Tue, 12 May 1998 10:50:33 -0400 (EDT)


On Mon, 11 May 1998, Scott L. Burson wrote:
> The technique Kragen suggests may have been studied, although I don't think I
> had heard of it, 

I read about it in a paper of Henry Baker's -- although there, it was
suggested that instead of calling fork(), you simply stop execution of
the mutator, copy its entire address space to somewhere else, and then
wake the mutator back up.  But I can't imagine that the person who
suggested this intended for it to be implemented in any way other than
using an MMU to do copy-on-write stuff.

> but it's not what's called a "write barrier".  

I didn't think it was.

> Kragen's suggestion is an intriguing one.  I'd have to think about it for a
> while to understand the tradeoffs.

Well, on most Unix machines, it will involve at least allocating enough
swap space to hold the entire address space if necessary, and possibly
actually copying the entire address space.  On Linux, it will only
involve allocating a new page table and process structure for the child
and enough swap space to hold whatever pages get mutated while the gc
is trying to scan them.

It implies certain restrictions on what you can do with your program --
you'll need to handle SIGCHLD in the gc code, and you'll need to mmap()
some memory shared so that you can talk to the child.  So if the
mutator uses SIGCHLD or wait() (or any of its variants), it needs to
talk to the gc about it so they don't stomp on each other.

Kragen