Re: GC questions.

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Michael Livshin <mlivshin@bigfoot.com> writes:

> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > * I am puzzled by GUILE_NEW_GC_SCHEME. What is it? Why is it optional?
> > It makes reading gc.c a pain.
> 
> it's "optional" (it's more correct to say that the old scheme is
> optional) because it's new.  I don't remember any bug reports about GC
> problems in last two months' CVS Guile, so perhaps it's time to
> completely remove the old scheme.  what does The Gang of Four think?

They think "yes".  :)

Will you remove the old code?

> > * I understood from Greg's notes, that one of the problems with
> > copying GC is how to deal with heap pointers in smobs? But isn't that
> > easy?  To deal with this requires a small API change: every object has
> > to be marked during GC, so how about defining a new function
> > get_new_location (), like this?
> > 
> >   struct smobstruct
> >   {
> >     SCM m1;
> >     SCM m2;
> >   };
> > 
> >   mark_smob (SCM ptr)
> >   {
> >     smobstruct *sp = gh_cdr (ptr);
> > 
> >     sp->m1 = scm_get_new_location (sp->m1);
> >     sp->m2 = scm_get_new_location (sp->m2);
> >   }
> > 
> > this breaks compatibility completely. It would be possible to fix this
> > up, by defining scm_gc_mark () to be an alias for the conservative
> > mark function.
> 
> I'm not sure I understand.  what is the relevant place in Greg's
> notes?

The idea is to improve the smob interface so that it is compatible
also with copying collectors.  It's an interesting idea.  We'll have
to think about this.