bpo-39489: Remove COUNT_ALLOCS special build (GH-18259)

Remove:

* COUNT_ALLOCS macro
* sys.getcounts() function
* SHOW_ALLOC_COUNT code in listobject.c
* SHOW_TRACK_COUNT code in tupleobject.c
* PyConfig.show_alloc_count field
* -X showalloccount command line option
* @test.support.requires_type_collecting decorator

1 files changed, 1 insertions, 52 deletions

diff --git a/Misc/SpecialBuilds.txt b/Misc/SpecialBuilds.txt
index d1a0321..27369ab 100644
--- a/Misc/SpecialBuilds.txt
+++ b/Misc/SpecialBuilds.txt
@@ -46,9 +46,7 @@ Build option: ``./configure --with-trace-refs``.
 Turn on heavy reference debugging.  This is major surgery.  Every PyObject grows
 two more pointers, to maintain a doubly-linked list of all live heap-allocated
 objects.  Most built-in type objects are not in this list, as they're statically
-allocated.  Starting in Python 2.3, if COUNT_ALLOCS (see below) is also defined,
-a static type object T does appear in this list if at least one object of type T
-has been created.
+allocated.
 
 Note that because the fundamental PyObject layout changes, Python modules
 compiled with Py_TRACE_REFS are incompatible with modules compiled without it.
@@ -165,55 +163,6 @@ by not defining NDEBUG), and some routines do additional sanity checks inside
 "#ifdef Py_DEBUG" blocks.
 
 
-COUNT_ALLOCS
-------------
-
-Each type object grows three new members:
-
-    /* Number of times an object of this type was allocated. */
-    int tp_allocs;
-
-    /* Number of times an object of this type was deallocated. */
-    int tp_frees;
-
-    /* Highwater mark:  the maximum value of tp_allocs - tp_frees so
-     * far; or, IOW, the largest number of objects of this type alive at
-     * the same time.
-     */
-    int tp_maxalloc;
-
-Allocation and deallocation code keeps these counts up to date.  Py_FinalizeEx()
-displays a summary of the info returned by sys.getcounts() (see below), along
-with assorted other special allocation counts (like the number of tuple
-allocations satisfied by a tuple free-list, the number of 1-character strings
-allocated, etc).
-
-Before Python 2.2, type objects were immortal, and the COUNT_ALLOCS
-implementation relies on that.  As of Python 2.2, heap-allocated type/ class
-objects can go away.  COUNT_ALLOCS can blow up in 2.2 and 2.2.1 because of this;
-this was fixed in 2.2.2.  Use of COUNT_ALLOCS makes all heap-allocated type
-objects immortal, except for those for which no object of that type is ever
-allocated.
-
-Starting with Python 2.3, If Py_TRACE_REFS is also defined, COUNT_ALLOCS
-arranges to ensure that the type object for each allocated object appears in the
-doubly-linked list of all objects maintained by Py_TRACE_REFS.
-
-Special gimmicks:
-
-sys.getcounts()
-    Return a list of 4-tuples, one entry for each type object for which at least
-    one object of that type was allocated.  Each tuple is of the form:
-
-        (tp_name, tp_allocs, tp_frees, tp_maxalloc)
-
-    Each distinct type object gets a distinct entry in this list, even if two or
-    more type objects have the same tp_name (in which case there's no way to
-    distinguish them by looking at this list).  The list is ordered by time of
-    first object allocation: the type object for which the first allocation of
-    an object of that type occurred most recently is at the front of the list.
-
-
 LLTRACE
 -------