From 50e03c55f4bd7d33e16db83a86b81b4b6969eeb6 Mon Sep 17 00:00:00 2001 From: Owen Carey <37121709+owenthcarey@users.noreply.github.com> Date: Thu, 3 Sep 2026 01:18:34 -0700 Subject: [PATCH] gh-122862: Fix description of the GC allocation counter in set_threshold() docs --- Doc/library/gc.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Doc/library/gc.rst b/Doc/library/gc.rst index 65533e7e57adc33..a7623c59af86912 100644 --- a/Doc/library/gc.rst +++ b/Doc/library/gc.rst @@ -124,12 +124,13 @@ The :mod:`!gc` module provides the following functions: generation (generation ``0``). If an object survives a collection it is moved into the next older generation. Since generation ``2`` is the oldest generation, objects in that generation remain there after a collection. In - order to decide when to run, the collector keeps track of the number object - allocations and deallocations since the last collection. When the number of - allocations minus the number of deallocations exceeds *threshold0*, collection - starts. Initially only generation ``0`` is examined. If generation ``0`` has - been examined more than *threshold1* times since generation ``1`` has been - examined, then generation ``1`` is examined as well. + order to decide when to run, the collector keeps a counter that is reset by + each collection, incremented by each object allocation, and decremented by + each object deallocation, but never below zero. When this counter exceeds + *threshold0*, collection starts. Initially only generation ``0`` is + examined. If generation ``0`` has been examined more than *threshold1* times + since generation ``1`` has been examined, then generation ``1`` is examined + as well. With the third generation, things are a bit more complicated, see `Collecting the oldest generation `_ for more information.