Re: Outline for Guile Generational GC

[Dale Jordan <dalej@alum.mit.edu>]

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.

> > 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?

  Dale.