[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. _______________________________________________ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LPD7GHOQBP6T7X4BUMTPCPKQRYEHFW35/ Code of Conduct: https://www.python.org/psf/codeofconduct/
