On 27.05.2021 19:40, Tim Peters wrote: > [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. >> ...
Thanks for these details. I wasn't aware of that change. So all those instances have an increase in memory footprint compared to Python 3.7 ? > 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. Indeed, that's what I was after. GC is really only needed for objects which can potentially participate in cycles which need to be reclaimed. As I understand the logic (even with the objects referencing the constant type objects on the heap), many of the objects which are now made GC traversal aware don't really have a need for it -- their traversal only finds type objects, no other objects. >>> ... >>> 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. 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. 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 ;-) Perhaps this provides an easy way to unblock the release :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 27 2021) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ 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/HGUX3BRDWONJPNZQSKEJLU3ZBOGGG3CM/ Code of Conduct: https://www.python.org/psf/codeofconduct/