This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients nascheme, pitrou, tim.peters
Date 2019-10-05.17:31:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
While people are thinking about gc, shows a small bug, and a possible opportunity for improvement, in the way gc treats finalizers that resurrect objects.

The bug:  the stats keep claiming gc is collecting an enormous number of objects, but in fact it's not collecting any.  Objects in the unreachable set shouldn't add to the "collected" count unless they _are_ collected.


collect 2000002
gen 2 stats {'collections': 2, 'collected': 2000002, 'uncollectable': 0}
collect 4000004
gen 2 stats {'collections': 3, 'collected': 6000006, 'uncollectable': 0}
collect 6000006
gen 2 stats {'collections': 4, 'collected': 12000012, 'uncollectable': 0}
collect 8000008
gen 2 stats {'collections': 5, 'collected': 20000020, 'uncollectable': 0}
collect 10000010
gen 2 stats {'collections': 6, 'collected': 30000030, 'uncollectable': 0}

Memory use grows without bound, and collections take ever longer.

The opportunity:  if any finalizer resurrects anything, gc gives up.  But the process of computing whether anything was resurrected also determines which initially-trash objects are reachable from the risen dead.  Offhand I don't see why we couldn't proceed collecting what remains trash.  Then would reclaim everything instead of nothing.

Sketch:  rather than just set a flag, check_garbage() could move now-reachable objects to the old generation (and, for each one moved, decrement the count of collected objects).  Then delete_garbage() could proceed on what remains in the unreachable list.
Date User Action Args
2019-10-05 17:31:26tim.peterssetrecipients: + tim.peters, nascheme, pitrou
2019-10-05 17:31:26tim.peterssetmessageid: <>
2019-10-05 17:31:26tim.peterslinkissue38379 messages
2019-10-05 17:31:25tim.peterscreate