This is the mail archive of the guile@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: Outline for Guile Generational GC


Dale Jordan <dalej@alum.mit.edu> writes:

> Greg Harvey wrote:
> 
> > I was thinking more along the lines of a per segment list that
> > contained the possible generations this segment could have objects
> > pointing to. For example, when we're collecting generation 2, we only
> > have to scan over segments that have generation 2 in their
> > possible_pointers list. Then, we can take the time to jump through the
> > segment, checking for pointers (if we don't find one, we beat up the
> > segment for lying to us, and remove 2 from the possible pointers
> > list). A lot of this depends on the implementation of the write
> > barrier, though I think it could work well with this.
> 
> I see.  Instead of a list, how about a bit map?  You don't have to
> worry about duplicates and it takes a fixed amount of storage.

Yep. I was using list to refer to a general collection of objects in
this case... that's what lisp does to your brain ;)

 
> > > What's SCM_ASSIGN?  My (rather outdated now) sources don't mention it.
> 
> > Possibly what will be required in c code with a write barrier, to do
> > the appropriate calculations.
> 
> > > Won't the required call to scm_gc_mark handle this?
> > > { user smobs with pointers }
> 
> > Not for alerting the write barrier of the location of possible
> > pointers. We can't catch these otherwise, since they're outside the
> > heap.
> 
> Well, they would normally be marked by a full scan; your point is that
> they may not be marked by a particular generation's scan.  This is bad
> news.   Basically, smobs are like a heap segment -- we need some sort
> of write barrier to record pointer stores into them or we need a way
> to trace all of them and force their mark functions to be called
> (ie. as if they were in the root set.)  A revised scm_gc_mark could
> ignore calls with pointers into the wrong generation.  Getting a list
> of all smobs might require an API change; so would a call to a write
> barrier function.  Would everyone tolerate this?

Dunno, which is the $50000 question right now (I'm personally don't
like it much, but I've been trying to figure out how it could be done
this way because the cost is probably lower).

The other idea I've been tossing around for this was to require all
user code to do allocation through guile (sort of like using
scm_must_malloc, I'm not sure if that's currently required of user
code), and do the page fault thing (not a trap on every write, but a
trap on a write to an older gen or protected memory, mark that page
dirty, and unprotect it). I know that the costs of both have been
discussed, and that the mem protect route can be expected to lose, but
it's also the most convienient way for the actual users of guile. If
the cost turns out the be too high, other routes can be explored, but
I'm not currently impressed by where those routes lead.
 
-- 
Greg