John Tobey wrote:
> Picture this. A Lisp (or Java, ...) structure holds a Perl
> interpreter. A Perl variable holds a reference to the Lisp structure.
> Structure and interpreter become inaccessible to all threads. Perl
> will never know it's done with the Lisp structure, neither Perl nor
> the structure will ever be collected, and we will have defeated
> mark-and-sweep.
In the normal case, lisp runs the finalizer when the perl structure
becomes garbage. In the finalizer, perl can erase the external
reference and then next time perl collects, the structure may be
marked as garbage. If you're talking about the situation where
an object is only reachable through a pointer held by an external
system, then lisp needs to use a two-phase finalization. First it
tells the foreign system (perl) that the object is considered
garbage except for the foreign reference. That allows perl to release
the reference and then the object really does become garbage. If perl
decides not to release, then the object remains a weak root. This is
a really weird situation though and I wouldn't be surprised if most
systems just ignore the possibility. Did you ever have this problem
or is it contrived?
Foreign references are not swept and can't be swept unless you
are building a gc system for non-cooperative environments (Boehm's
collector for example) and they have a *lot* of constraints that
most lisp systems I know of violate. The theoretical cycle won't
be found.
There's a lot of talk about doing a mark-sweep collector for perl,
but I'm not sure adopting a 30 year old obsolete gc algorithm is
such a good idea. Certainly we have to be careful about moving
objects, but generational collectors have a lot of advantages we
should consider. (A trivial malloc for any size object is the one
that's probably most important for us: obj = heap_top; heap_top +=
obj_size.) (I should say generational copying collector, since
generational mark-sweep is also possible, but rare.) On the other
hand, mark-sweep doesn't have the page thrashing problems of the
simple hemi-space copying collectors. There was an Italian collector
for C++ that had multiple arenas with different strategies for
each arena. That might be a useful concept to adopt. (I'll try to
dig up a reference.)
- Ken
