blob: b332fe22dcacd4879dbe1b9d81e291024e20f724 [file] [log] [blame]
Fred Drakebdcf91f2000-07-12 04:22:53 +00001\section{\module{gc} ---
2 Garbage Collector interface}
3
4\declaremodule{extension}{gc}
Fred Drakee5441912000-09-09 03:26:51 +00005\modulesynopsis{Interface to the cycle-detecting garbage collector.}
Neil Schemenauerb2c2c9e2000-10-04 16:34:09 +00006\moduleauthor{Neil Schemenauer}{nas@arctrix.com}
7\sectionauthor{Neil Schemenauer}{nas@arctrix.com}
Fred Drakebdcf91f2000-07-12 04:22:53 +00008
Fred Drakee5441912000-09-09 03:26:51 +00009The \module{gc} module is only available if the interpreter was built
10with the optional cyclic garbage detector (enabled by default). If
11this was not enabled, an \exception{ImportError} is raised by attempts
12to import this module.
13
Vladimir Marangozovf9d20c32000-08-06 22:45:31 +000014This module provides an interface to the optional garbage collector. It
15provides the ability to disable the collector, tune the collection
Fred Drakebdcf91f2000-07-12 04:22:53 +000016frequency, and set debugging options. It also provides access to
Vladimir Marangozovf9d20c32000-08-06 22:45:31 +000017unreachable objects that the collector found but cannot free. Since the
18collector supplements the reference counting already used in Python, you
19can disable the collector if you are sure your program does not create
20reference cycles. Automatic collection can be disabled by calling
21\code{gc.disable()}. To debug a leaking program call
Fred Drakebdcf91f2000-07-12 04:22:53 +000022\code{gc.set_debug(gc.DEBUG_LEAK)}.
23
24The \module{gc} module provides the following functions:
25
Vladimir Marangozovf9d20c32000-08-06 22:45:31 +000026\begin{funcdesc}{enable}{}
27Enable automatic garbage collection.
28\end{funcdesc}
29
30\begin{funcdesc}{disable}{}
31Disable automatic garbage collection.
32\end{funcdesc}
33
34\begin{funcdesc}{isenabled}{}
35Returns true if automatic collection is enabled.
36\end{funcdesc}
37
Fred Drakebdcf91f2000-07-12 04:22:53 +000038\begin{funcdesc}{collect}{}
39Run a full collection. All generations are examined and the
40number of unreachable objects found is returned.
41\end{funcdesc}
42
43\begin{funcdesc}{set_debug}{flags}
44Set the garbage collection debugging flags.
45Debugging information will be written to \code{sys.stderr}. See below
46for a list of debugging flags which can be combined using bit
47operations to control debugging.
48\end{funcdesc}
49
50\begin{funcdesc}{get_debug}{}
51Return the debugging flags currently set.
52\end{funcdesc}
53
54\begin{funcdesc}{set_threshold}{threshold0\optional{,
55 threshold1\optional{, threshold2}}}
56Set the garbage collection thresholds (the collection frequency).
57Setting \var{threshold0} to zero disables collection.
58
59The GC classifies objects into three generations depending on how many
60collection sweeps they have survived. New objects are placed in the
61youngest generation (generation \code{0}). If an object survives a
62collection it is moved into the next older generation. Since
63generation \code{2} is the oldest generation, objects in that
64generation remain there after a collection. In order to decide when
65to run, the collector keeps track of the number object allocations and
66deallocations since the last collection. When the number of
67allocations minus the number of deallocations exceeds
68\var{threshold0}, collection starts. Initially only generation
69\code{0} is examined. If generation \code{0} has been examined more
70than \var{threshold1} times since generation \code{1} has been
71examined, then generation \code{1} is examined as well. Similarly,
72\var{threshold2} controls the number of collections of generation
73\code{1} before collecting generation \code{2}.
74\end{funcdesc}
75
76\begin{funcdesc}{get_threshold}{}
77Return the current collection thresholds as a tuple of
78\code{(\var{threshold0}, \var{threshold1}, \var{threshold2})}.
79\end{funcdesc}
80
Martin v. Löwis560da622001-11-24 09:24:51 +000081\begin{funcdesc}{get_referrers}{*objs}
82Return the list of objects that directly refer to any of objs. This
83function will only locate those containers which support garbage
84collection; extension types which do refer to other objects but do not
85support garbage collection will not be found.
86\versionadded{2.2}
87\end{funcdesc}
Fred Drakebdcf91f2000-07-12 04:22:53 +000088
Tim Petersaf0a8832001-11-18 04:51:17 +000089The following variable is provided for read-only access (you can
90mutate its value but should not rebind it):
Fred Drakebdcf91f2000-07-12 04:22:53 +000091
92\begin{datadesc}{garbage}
93A list of objects which the collector found to be unreachable
Tim Peters169ded02001-11-03 19:57:21 +000094but could not be freed (uncollectable objects). By default, this list
95contains only objects with \method{__del__()} methods.\footnote{Prior to
96 Python 2.2, the list contained all instance objects in unreachable
97 cycles, not only those with \method{__del__()} methods.}
98Objects that have
Tim Petersaf0a8832001-11-18 04:51:17 +000099\method{__del__()} methods and are part of a reference cycle cause
100the entire reference cycle to be uncollectable, including objects
101not necessarily in the cycle but reachable only from it. Python doesn't
102collect such cycles automatically because, in general, it isn't possible
103for Python to guess a safe order in which to run the \method{__del__()}
104methods. If you know a safe order, you can force the issue by examining
105the \var{garbage} list, and explicitly breaking cycles due to your
106objects within the list. Note that these objects are kept alive even
107so by virtue of being in the \var{garbage} list, so they should be
108removed from \var{garbage} too. For example, after breaking cycles, do
109\code{del gc.garbage[:]} to empty the list. It's generally better
110to avoid the issue by not creating cycles containing objects with
111\method{__del__()} methods, and \var{garbage} can be examined in that
Fred Drakedda7dcb2001-12-14 21:19:08 +0000112case to verify that no such cycles are being created.
Tim Petersaf0a8832001-11-18 04:51:17 +0000113
114If \constant{DEBUG_SAVEALL} is set, then all unreachable objects will
Neil Schemenauer544de1e2000-09-22 15:22:38 +0000115be added to this list rather than freed.
Fred Drakebdcf91f2000-07-12 04:22:53 +0000116\end{datadesc}
117
118
119The following constants are provided for use with
120\function{set_debug()}:
121
122\begin{datadesc}{DEBUG_STATS}
123Print statistics during collection. This information can
124be useful when tuning the collection frequency.
125\end{datadesc}
126
127\begin{datadesc}{DEBUG_COLLECTABLE}
128Print information on collectable objects found.
129\end{datadesc}
130
131\begin{datadesc}{DEBUG_UNCOLLECTABLE}
132Print information of uncollectable objects found (objects which are
133not reachable but cannot be freed by the collector). These objects
134will be added to the \code{garbage} list.
135\end{datadesc}
136
137\begin{datadesc}{DEBUG_INSTANCES}
138When \constant{DEBUG_COLLECTABLE} or \constant{DEBUG_UNCOLLECTABLE} is
139set, print information about instance objects found.
140\end{datadesc}
141
142\begin{datadesc}{DEBUG_OBJECTS}
143When \constant{DEBUG_COLLECTABLE} or \constant{DEBUG_UNCOLLECTABLE} is
144set, print information about objects other than instance objects found.
145\end{datadesc}
146
Neil Schemenauer544de1e2000-09-22 15:22:38 +0000147\begin{datadesc}{DEBUG_SAVEALL}
148When set, all unreachable objects found will be appended to
149\var{garbage} rather than being freed. This can be useful for debugging
150a leaking program.
151\end{datadesc}
152
Fred Drakebdcf91f2000-07-12 04:22:53 +0000153\begin{datadesc}{DEBUG_LEAK}
154The debugging flags necessary for the collector to print
155information about a leaking program (equal to \code{DEBUG_COLLECTABLE |
Tim Petersaf0a8832001-11-18 04:51:17 +0000156DEBUG_UNCOLLECTABLE | DEBUG_INSTANCES | DEBUG_OBJECTS | DEBUG_SAVEALL}).
Fred Drakebdcf91f2000-07-12 04:22:53 +0000157\end{datadesc}