Re: GUILE GC -- Write barrier for vectors

[Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>]

On Mon, 15 Jul 2002 hanwen@cs.uu.nl wrote:

> Linked against 1.7.0 without-threads, lily uses approximately 20% of
> its time in GC on a 400 mhz PII/SDRAM. In another instance, the same
> compile with lilypond linked against 1.5.6 on a 1Ghz PIII/DDR RDRAM,
> uses approximately 50% of the total running time (!) for GC'ing.

Marius has cleaned up the memory interface.  During this step, a couple of
bugs were removed, where guile reports too much memory being allocated to
the gc.  This caused the gc to be called more often than necessary.  You
can find some details under workbook/gc/memory.text.  Possibly these
changes account for part of the difference between CVS (1.7.0 ?) and
1.5.6.

> In any case, it seems that there is room for improvement on the GUILE
> side, and one of these would be generational GC.

Right.  I think Michael Livshin has already thought about that issue.  You
should probably contact him to share ideas.  I think, summarizing all
thoughts in workbook will be quite helpful.

> Also, smobs and maybe some other types (which ones? structs?), are
> always assumed to have been changed, since they are outside of GC's
> control. It would probably be best to allocate them from a different
> pool so that they won't poison the normal generations, but that would
> require a slight extension of the GUILE API.

Do you have a suggestion for such an extension?

> As a prelude, I tried to add a "soft" write barrier to the vector
> code, by returning a const* in SCM_VELTS, and fixing where it goes
> wrong. The cell codes already have this type of write barrier. I then
> tried to fix up the remaining parts of the code. This is required by
> any gen GC code, IIRC.
[...]
> * I introduced the SCM_VECTOR_SET macro, ie
> 
> 	SCM_VECTOR_SET(vec,idx,value);
> 
> must be used for assignment.

Great.  This is a very good change, not just for the sake of gengc.

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

Btw:  We should also try to get rid of SCM_CARLOC and SCM_CDRLOC in this
context...

> * I ran a GC test just to verify that it was working, but I would
> really like to run the test-suite; I think that the following is a
> disgrace:

Well, can't tell you about this one, since I am personally not doing
"make check" but rather "./check-guile" from the guile-core directory.

> * 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.

> * Et ceteram censeo GUILE 1.6 releasem esse
:-)

Best regards,
Dirk Herrmann


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel