This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]