Stowage/cpython
2
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2026-01-08 16:32:55 +00:00
Code Issues Projects Releases Packages Wiki Activity

Moved COUNT_ALLOCS down and finished writing its description.

Browse source
This commit is contained in:
Tim Peters 2002-07-09 19:24:54 +00:00
parent 3486f617a1
commit 48ba649ae3
1 changed files with 45 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

51
Misc/SpecialBuilds.txt
View file

@ -53,12 +53,6 @@ envar PYTHONDUMPREFS
If this envar exists, Py_Finalize() arranges to print a list of
all still-live heap objects.
---------------------------------------------------------------------------
COUNT_ALLOCS
Special gimmicks:
sys.getcounts()
---------------------------------------------------------------------------
PYMALLOC_DEBUG
Special gimmicks:
@ -75,3 +69,48 @@ This is what is generally meant by "a debug build" of Python.
Py_DEBUG implies Py_REF_DEBUG, Py_TRACE_REFS, and PYMALLOC_DEBUG (if
WITH_PYMALLOC is enabled).
---------------------------------------------------------------------------
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_Finalize() 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.
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 objects 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.
---------------------------------------------------------------------------