Re: GUILE GC -- Write barrier for vectors

[Dirk Herrmann]

On Mon, 15 Jul 2002, Han-Wen Nienhuys wrote:

> > Do you have a suggestion for such an extension?
> 
>       SCM scm_changing_cell()
>       SCM scm_changing_vector()
> 
> They would be allocated from a separate memory pool. Also if we
> redefine the GC engine to use a different function internally
> (i.e. scm_gc_internal_mark), then we can distinguish between data
> cells that may be moved (only pointed to from within the heap), and
> other cells (marked by scm_gc_mark: conservatively marked entries,
> pointed to from smobs, etc.).
> 
> The copiable cells could be subjected to copying GC, although it would
> require another scan of the entire heap.

It's a good idea - unfortunately it is patented.  Don't ask me who has
this patented, but I also suggested this idea some time ago.  That's the
bad thing about patents:  Whenever there's a good idea, you can't be sure
it is patented.

But, it may make sense to investigate this patent issue again.  Maybe the
information above is outdated and the idea can actually be used in free
software?

In this case, I wouldn't like to have the API extended as you suggest
above:  Then it would be easy to re-arrange cells in cards such that
untouched cells are moved into common cards - no need to extend the API.

> >I think, summarizing all thoughts in workbook will be quite helpful.
> 
> I much prefer comments in the  source code. If you're serious about
> hacking that's the first place where you go looking anyways.

This is true if there is code.  As long as there is just a conceptual
phase, there is no code to comment on.  And, the current situation is a
counterexample to your suggestion:  If we had started the workbook idea
sooner, we would not have to go around asking for things about gc that
others have already thought about.

> > > * Direct write access to a vector must be done through the macro
> > > SCM_WRITABLE_VELTS.
> > 
> > Hmmm?  Where should this be necessary?  Do you want to modify the vector
> > cell itself, or are you using this for "speed ups"?  In the "speed-up"
> > case:  wouldn't SCM_VECTOR_SET do as well, given that the compiler can
> > extract constant expressions from within loops?
> 
> In some cases no (GC manipulations of weak vectors), and in some cases
> yes, but it would introduce lots of redtape: long lists of
> SCM_VECTOR_SET calls. I'll review the cases once more. 

GC manipulations of weak vectors?  These shouldn't require any write
barrier.  And, even if so, there's already SCM_SET_WVECT_GC_CHAIN.

> > > * Will this patch be integrated into CVS?  The FSF already has
> > >   disclaimers for me.
> > 
> > I have not looked into the patch yet, but I think that the SCM_VECTOR_SET
> > patch as you describe it is probably the right thing to do.  I am not sure
> > about the need for SCM_WRITABLE_VELTS, but I think we can discuss this
> > one.  In any case, it would be great if you could contact Michael Livshin.
> 
> I assume he is still on the list, reading all my musings? Also I
> noticed that Greg Harvey did a lot of work on gengc, but apparently
> that didn't work very well?

I think that Michael took over some stuff from Greg Harvey.  Again:
Please don't wait to write down your thoughts until there is code.

Best regards,
Dirk