This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Lilypond, GUILE and Garbage Collection (again)



Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> > 3. Using SMOBs to mark the alists using C++ code.
> 
> This is probably also a very good solution, but I don't know how this fits
> into Greg Harveys approach to improve and generalize guile's garbage
> collection.  

Provided is uses scm_gc_mark, rather than trying to set the marks
itself, it should work fine with any particular gc implementation.
 
> It also reminds me of an old idea I once presented to the list:  Having to
> define some SMOB just in order to get the garbage collection right still
> seems strange to me.  You probably define the SMOB, create one
> single object of it that is put into the scm_protect list and that is all 
> you need that SMOB for. Instead, the garbage collector could have a set of
> functions that are called during garbage collection time and that report
> cells which are still in use to the collector.  For your case this would
> mean that you would not have to create a SMOB for marking, but you rather
> would (at program start) report the mark function to the garbage
> collector.  -- Greg: Would it be possible / make sense to combine such an
> approach with your garbage collector?

I've thought about this, but I'm not fussy; the essential problem is
that all of these functions will need to know exactly how the gc
works; it has to figure out what objects should be returned, for
example, and this could easily change; if not, it means the gc has to
look at, in the specific example given, 100,000 objects to figure out
if it actually cares about them during this collection, which sort of
toasts the whole idea of a generational collector.

While the smob approach does sometimes seem like a bit of overkill, it
does mean that the gc gets to figure out the more complicated
stuff. So the question is whether having the ability to add functions
to the gc is, in fact, adding anything to the whole process, or is it
just complicating the gc?

There's still the question of whether the smob space is large enough
to accomidate this... it doesn't seem to be biting anyone, though.

-- 
Greg