[Pablo Galindo Salgado <pablog...@gmail.com>] > Hi Marc, > > Yes, check out this from the 3.9 what's new document: > > https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api > > Instances of heap-allocated types (such as those created with > PyType_FromSpec() > and similar APIs) hold a reference to their type object since Python 3.8. > ...
I think Marc-Andre's question is more subtle than that: [Marc-Andre Lemburg, <m...@egenix.com>] >> Hi Pablo, >> >> could you or Erlend please explain why types which don't reference >> any other objects need to participate in GC for deallocation ? ... >> AFAIK (but could be wrong, of course), the type object itself >> does not reference any other objects related to the object >> that is being GCed. To make that more formal, if there's a chain of pointers from an object X that reaches X again (X is a direct member of a cycle), then for cyclic gc to work X's tp_traverse must visit all directly contained objects that could be the second object in a direct cycle reaching X again. But, for example, if X contains a tuple of integers, there's no need for X's tp_traverse to visit that tuple. It's impossible to reach X from the tuple. Cyclic gc cares only about cycles; chasing non-cyclic dead ends doesn't accomplish anything beyond burning processor cycles. This is, I believe, akin to what Marc-Andre is bringing up: if X can't be reached _from_ X's type object, there's no need for X's tp_traverse to visit X's type object. It _can_ be visited, but it would be a waste of time. >> ... >> By having (nearly) all stdlib types participate in GC, even ones >> which don't reference other objects and cannot be parts of reference >> circles, instead of immediately deleting them, we will keep those >> objects alive for much longer than necessary, potentially causing a >> resource overhead regression. 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. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/QLJ2H6OCM2B3UR6JTKNPTSDXQIH4P4QB/ Code of Conduct: https://www.python.org/psf/codeofconduct/
