John Tobey wrote:
> But if we anticipate possibly implementing mark-and-sweep
We're definitely going to have some sort of traversing collector. It
might only augment the ref count collector. The ref count might be 5
bits at the bottom of flags and we can do this:
enum gc_flags { sticky = 16 };
if (!(flags & sticky)) {
++flags;
}
If the ref count ever hits 16, the object won't be deallocated by
the ref count collector, but the traversing collector will find it.
I have way too much existing Perl code that creates cycles -- the
opportunity to fix all those bugs won't come again for a long time.
> our mark routine should call Lisp's mark routine on those Lisp objects
> we still reference, which would allow those we don't to be collected.
In general it isn't going to be possible to integrate tightly with a
foreign collector. For example, most lisp systems don't use mark-sweep
so it's not possible to have them sweep for foreign perl references.
What we should plan on doing is notifying the foreign system when
we've dropped the last reference to one of its objects. If the foreign
system ** isolates foreign references (duplicates the reference so it
doesn't have to special case the collector) then it will be easy
for it to sync with us. Perl should use the same approach.
- Ken
** In most of the language integrations we want (python, guile,
librep, etc.) we'll have to write both sides anyways.
