incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Reference counting inside a GC host (was "real time updates")
Date Sun, 29 Mar 2009 10:01:16 GMT
On Sat, Mar 28, 2009 at 6:55 PM, Marvin Humphrey <> wrote:
> On Fri, Mar 27, 2009 at 08:23:45AM -0400, Michael McCandless wrote:
>> since Lucy will use reference counting, how will you deal with cycles?
> I don't think we should do anything about them.  It will be up to the user to
> avoid them.
> There *are* limits to my ambitions for the Lucy object model.  :)

OK :)  Intentionally leaky abstraction.  FWIW Python took that same
approach for many years, before sprouting a cycle detector addition to
its GC.  But it's awkward, because sometimes things are collected
immediately (when they decref to 0), but at other times, only when the
cyclic collector sweeps.  And of course, because it's tracing, it
requires each class to expose a "visit all things I refer to" API.

You might consider adding the hooks for a tracing collector, but not
creating such a collector now.  IE have each Lucy obj expose a method
to visit the other objs it refers to.

>> since the host language is involved, a cycle could easily reach out to the
>> host language and wrap back around into Lucy?
> Possible.  I doubt it will be much of a problem for programmers accustomed to
> working within a refcounted environment.

I think you'd be surprised at how easily cycles are accidentally created.

It's sort of like saying programmers are accustomed to writing high
performance code, but then an O(N^2) slips in somewhere and goes
undetected until N happens to get large deep in production.

> Programmers who normally work within a tracing GC environment may be more
> prone to create reference cycles, because they're not trained to avoid
> cyclical data structures and alarms might not go off in their heads when they
> see them.
> But what are our options?  Our class hierarchy is sophisticated and large
> enough that we have to use either tracing GC or refcounting.  Writing our own
> tracing GC, now *that* would be ambitious. ;)  And though I haven't studied
> cycle detection, I imagine it has to be both involved and costly.

Agreed.  I wonder if there's a decent tracing GC library somehow out
there, that only requires certain limited methods to be exposed for
your objects...

And note that I'm really playing devil's advocate here -- I don't have
good solutions to offer for these hard problems.


View raw message