This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: GC and threads (was Re: generational GC)
> > For example, suppose we mark the global roots first, and leave
> > scanning the threads' stacks at the very end. When a thread allocates
> > a new cell, we can color the new cell white if the thread's stack
> > hasn't been scanned yet, or black if it has. That way, if we can
> > reach a good portion of the heap through the global roots, we can do
> > most of our allocation white, and those cells can be reclaimed at the
> > end of this GC cycle.
>
> I don't think that's quite enough. Consider:
>
> one thread calls a C routine
> c_routine creates objects o1 and o2, keeps references locally
> GC starts, scanning global roots
> GC scans binding of Scheme variable x containing a hash table
> c_routine creates o3, a pair containing o1 and #t
> c_routine sets cdr of o3 to o2
> c_routine stores o3 in hash table x
> c_routine discards references to o1, o2, o3
> GC finishes with global roots, starts scanning thread stacks
>
> So, the scanner misses all three objects, even those created before
> the GC pass started.
Whoa --- I was just answering a question about how new cell allocation
relates to concurrent GC. I had no intention of presenting a complete
concurrent GC algorithm in a casual post.
Yes, async GC needs write barriers. There are several kinds of write
barriers that assure correctness, some more efficient than others.