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: Marking smobs for GC


Marius Vollmer <mvo@zagadka.ping.de> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > > You mean, I could just let the proxy/widget move into a guardian when
> > > there are no references to it from Scheme and then, after the GC, do
> > > the internal reference boogie to find out which of them are really
> > > dead and resurrect the rest?  Yes, that could work.  It would be
> > > basically the same as what I'm doing now, but probably more efficient.
> > 
> > Actually, you could just slap it into a guardian from the beginning,
> > and look at the dead ones after collection. If they aren't really
> > dead, put them back into the guardian. 
> 
> I don't know how guardians really work...

Basically, they're like a generalization of weak pointers, except
instead of freeing objects that aren't traced, it marks them and puts
them in the zombie portion on the guardian, so that you can do what
you like with the objects that died (and they live on until you
retrieve them). As an example, say you wanted to reimplement weak
vectors; you could create a new object type that contained a vector of
SCM's (but didn't trace the values in it) and a guardian, which would
contain each of the values added to the weak vector (or, more likely,
a pair, so that you could get to the index of the object
quickly). After a collection, you'd just drop all of the zombie
objects, and shift around the vector. 

It's quite a schemy notion, really, being somewhat abstract and
allowing you to implement all sorts of funky data structures. There is
a paper out there somewhere, but I can't remember where I got it
(probably at www.schemers.org)

> > Here's how I understand it: you have a widget foo, that you just
> > created. On the gtk side of things, it keeps a reference count; on the
> > scheme side of things, you put the scheme object of the widget into
> > the widget guardian. You do a bunch of stuff, and then all references
> > to foo's scheme object are dropped. On the next collection, foo
> > becomes a zombie. After that, you look at the widget zombies. foo
> > still has a gtk refcount greater than 1, so you put foo back into the
> > guardian.
> 
> Almost.  I have to look if that widget has a refcount greater than its
> internal refcount, to defeat cycles.  Finding the internal refcount
> involves running over all widgets in the guardian, whether zombie or
> not.  This can be avoided when there are no zombies in the guardian
> which would be a win over the current scheme.  But I think guardians
> have their cost, too, no?
> 

Without looking at the code, I'd figure that the cost of the guardian
stuff is basically just the cost of the number of objects being
guarded (it will have to look through between marking and sweeping to
figure out which objects weren't traced, then do a mark on them to
prevent them from being freed, then put them in a queue). More than
performance boosts, though, it might be more convienient to do it with
built-in features, rather than having to roll your own; at this point,
though, it's probably not worth the trouble it would take to modify
guile-gtk to use guardians.


-- 
Greg