GC and threads (was Re: generational GC)

[Neil Jerram <neil at ossau dot uklinux dot net>]

Michael Livshin writes:

   just keep in mind that generational GC is not a blue-sky item anymore, 
   so react.

I don't know the research in this area at all, but it seems to me
that, given a multi-threaded Guile, it ought to be possible to do GC
(generational or not) asynchronously on a dedicated GC thread, rather
than on the threads that are executing Scheme programs.  This would be
useful in that any real-time guarantee that the OS provides for a
specified thread could be made available to the main line of a Scheme
program.

(In case it's not obvious what I mean, here's what I have in mind for
the case with 1 program thread + 1 GC thread.  Whenever the program
creates a new cell, it marks it with the current "GC cycle counter" C.
When (roughly) the program thread thinks that GC is desirable, it
stores the cycle counter and the top and bottom of the thread stack in
globals (Cstored = C etc.) that the GC thread can access, increments
the cycle counter, and signals the GC thread.  The GC thread marks as
usual, using the program thread's stored stack address range as well
as its own stack, but ignoring cells with cycle counter greater than
the counter stored in the program thread's global cycle counter
variable.  It then sweeps, again ignoring (i.e. not collecting) cells
with a recent cycle counter (C > Cstored).

The key point here is that it is impossible for a recent cell to
reference a non-recent cell unless that non-recent cell was also
accessible from the thread's stack and global starting points at the
time that the cycle counter was incremented.

I think this generalizes to >1 program thread, but I haven't worked it
out yet.)

Thoughts?  (Surely this can't be a new idea.)

    Neil