[Tim]
>> But I think "waste of time" is the worst of it. Participating in
>> cyclic gc does nothing to delay refcounting from recycling objects
>> ASAP. gc only reclaims objects that are reachable only from dead
>> cycles; everything else in CPython is reclaimed the instant its
>> refcount falls to 0, and that's so regardless of whether it
>> participates in cyclic gc.
[Marc-Andre Lemburg]
> Oh, thanks for the explanation. I was under the impression that
> GC-aware objects are added to a GC pool for processing at the
> next GC run.
At creation, they're added to "the youngest GC generation", which is a
doubly-linked list. It's doubly-linked precisely so (among other
things ;-) ) they can be removed from the youngest generation in O(1)
time if refcounting destroys them before the next GC run. GC only
looks at the objects still in the doubly-linked list when it runs. The
only effect it has on refcounting is to increase the time it takes
refcounting to do reclamation (refcounting has to adjust the
double-linked list pointers, to reflect that the object no longer
exists).
> If that's not the case in general -- only if they
> are part of dead cycles -- then it's merely wasting time on
> traversing known dead ends... and developer time for adding the
> unnecessary logic ;-)
And some conceptual confusion. For example, I noted in a later message
that we've apparently added a tp_traverse to regexp pattern objects.
"Why?" is baffling to me: how could they possibly participate in a
cycle? My best guess is that there's no need for them to participate
in cyclic gc at all, despite that - sure - they have a type pointer.