Re: Guile v2 and GC

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> Hello David,
>
> I saw that you made (some) changes for dealing with the Guile v2
> garbage collector. what is the overall status of this?

The known problems are patched up.

> Have you considered defining an operator new() for the smob types? It
> would call scm_gc_malloc. Wouldnt that take care of the whole messy
> derived_mark business?

The whole messy derived_mark business is there for a reason.  LilyPond's
data structures are large and LilyPond fills almost all the available
address space on 32bit systems.

In spite of our targeted mark passes, we still had the occasional
"Object should be dead" message, just from conservatively marking the
stack (and explicitly garbage collecting at a known low tide point).

And you are not going to win this by scm_gc_alloc-ing the memory of the
smob types anyway: you need custom alloc overrides for all of the STL
class arrays containing SCM values of some kind as well.

And of course you know that _lot_ of SCM values are not even stored
explicitly but as structure pointers that still need ->self () calls to
actually get a recognizable SCM value out.

Until all of your derived_mark calls look like

   scm_gc_mark (field1_);
   scm_gc_mark (field2_);
   scm_gc_mark (field3_);
   for (i=0; i<sizeof (c_array_fields_)/sizeof (*c_array_fields_); i++)
     scm_gc_mark (c_array_fields_[i]);

and nothing else, you are not going to have a lot of fun with your
scheme.

-- 
David Kastrup