2000-06-30 05:02:53 +00:00
|
|
|
/*
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
Reference Cycle Garbage Collection
|
|
|
|
|
==================================
|
|
|
|
|
|
2000-10-04 16:34:09 +00:00
|
|
|
Neil Schemenauer <nas@arctrix.com>
|
2000-06-30 05:02:53 +00:00
|
|
|
|
|
|
|
|
Based on a post on the python-dev list. Ideas from Guido van Rossum,
|
|
|
|
|
Eric Tiedemann, and various others.
|
|
|
|
|
|
2001-08-30 00:05:51 +00:00
|
|
|
http://www.arctrix.com/nas/python/gc/
|
2000-06-30 05:02:53 +00:00
|
|
|
http://www.python.org/pipermail/python-dev/2000-March/003869.html
|
|
|
|
|
http://www.python.org/pipermail/python-dev/2000-March/004010.html
|
|
|
|
|
http://www.python.org/pipermail/python-dev/2000-March/004022.html
|
|
|
|
|
|
|
|
|
|
For a highlevel view of the collection process, read the collect
|
|
|
|
|
function.
|
|
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "Python.h"
|
|
|
|
|
|
|
|
|
|
#ifdef WITH_CYCLE_GC
|
|
|
|
|
|
2001-08-30 00:05:51 +00:00
|
|
|
/* Get an object's GC head */
|
|
|
|
|
#define AS_GC(o) ((PyGC_Head *)(o)-1)
|
|
|
|
|
|
|
|
|
|
/* Get the object given the GC head */
|
|
|
|
|
#define FROM_GC(g) ((PyObject *)(((PyGC_Head *)g)+1))
|
|
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
|
|
|
|
|
/*** Global GC state ***/
|
|
|
|
|
|
|
|
|
|
/* linked lists of container objects */
|
2001-10-12 20:52:48 +00:00
|
|
|
PyGC_Head _PyGC_generation0 = {{&_PyGC_generation0, &_PyGC_generation0, 0}};
|
|
|
|
|
static PyGC_Head generation1 = {{&generation1, &generation1, 0}};
|
|
|
|
|
static PyGC_Head generation2 = {{&generation2, &generation2, 0}};
|
2000-06-30 05:02:53 +00:00
|
|
|
static int generation = 0; /* current generation being collected */
|
|
|
|
|
|
|
|
|
|
/* collection frequencies, XXX tune these */
|
2000-08-06 22:45:31 +00:00
|
|
|
static int enabled = 1; /* automatic collection enabled? */
|
2000-09-05 15:44:50 +00:00
|
|
|
static int threshold0 = 700; /* net new containers before collection */
|
2000-06-30 05:02:53 +00:00
|
|
|
static int threshold1 = 10; /* generation0 collections before collecting 1 */
|
|
|
|
|
static int threshold2 = 10; /* generation1 collections before collecting 2 */
|
|
|
|
|
|
|
|
|
|
/* net new objects allocated since last collection */
|
|
|
|
|
static int allocated;
|
|
|
|
|
|
2001-08-30 00:05:51 +00:00
|
|
|
/* true if we are currently running the collector */
|
|
|
|
|
static int collecting;
|
|
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
/* set for debugging information */
|
|
|
|
|
#define DEBUG_STATS (1<<0) /* print collection statistics */
|
|
|
|
|
#define DEBUG_COLLECTABLE (1<<1) /* print collectable objects */
|
|
|
|
|
#define DEBUG_UNCOLLECTABLE (1<<2) /* print uncollectable objects */
|
|
|
|
|
#define DEBUG_INSTANCES (1<<3) /* print instances */
|
|
|
|
|
#define DEBUG_OBJECTS (1<<4) /* print other objects */
|
2000-09-22 15:22:38 +00:00
|
|
|
#define DEBUG_SAVEALL (1<<5) /* save all garbage in gc.garbage */
|
2000-06-30 05:02:53 +00:00
|
|
|
#define DEBUG_LEAK DEBUG_COLLECTABLE | \
|
|
|
|
|
DEBUG_UNCOLLECTABLE | \
|
|
|
|
|
DEBUG_INSTANCES | \
|
2000-09-22 15:22:38 +00:00
|
|
|
DEBUG_OBJECTS | \
|
|
|
|
|
DEBUG_SAVEALL
|
2000-09-01 02:47:25 +00:00
|
|
|
static int debug;
|
2000-06-30 05:02:53 +00:00
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* When a collection begins, gc_refs is set to ob_refcnt for, and only for,
|
|
|
|
|
* the objects in the generation being collected, called the "young"
|
|
|
|
|
* generation at that point. As collection proceeds, when it's determined
|
|
|
|
|
* that one of these can't be collected (e.g., because it's reachable from
|
|
|
|
|
* outside, or has a __del__ method), the object is moved out of young, and
|
|
|
|
|
* gc_refs is set to a negative value. The latter is so we can distinguish
|
|
|
|
|
* collection candidates from non-candidates just by looking at the object.
|
|
|
|
|
*/
|
|
|
|
|
/* Special gc_refs value, although any negative value means "moved". */
|
2001-08-30 00:05:51 +00:00
|
|
|
#define GC_MOVED -123
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* True iff an object is still a candidate for collection. */
|
|
|
|
|
#define STILL_A_CANDIDATE(o) ((AS_GC(o))->gc.gc_refs >= 0)
|
|
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
/* list of uncollectable objects */
|
|
|
|
|
static PyObject *garbage;
|
|
|
|
|
|
2000-09-01 02:47:25 +00:00
|
|
|
/* Python string to use if unhandled exception occurs */
|
|
|
|
|
static PyObject *gc_str;
|
2000-06-30 05:02:53 +00:00
|
|
|
|
|
|
|
|
/*** list functions ***/
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
gc_list_init(PyGC_Head *list)
|
|
|
|
|
{
|
2001-10-11 18:31:31 +00:00
|
|
|
list->gc.gc_prev = list;
|
|
|
|
|
list->gc.gc_next = list;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
gc_list_append(PyGC_Head *node, PyGC_Head *list)
|
|
|
|
|
{
|
2001-10-11 18:31:31 +00:00
|
|
|
node->gc.gc_next = list;
|
|
|
|
|
node->gc.gc_prev = list->gc.gc_prev;
|
|
|
|
|
node->gc.gc_prev->gc.gc_next = node;
|
|
|
|
|
list->gc.gc_prev = node;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
gc_list_remove(PyGC_Head *node)
|
|
|
|
|
{
|
2001-10-11 18:31:31 +00:00
|
|
|
node->gc.gc_prev->gc.gc_next = node->gc.gc_next;
|
|
|
|
|
node->gc.gc_next->gc.gc_prev = node->gc.gc_prev;
|
|
|
|
|
node->gc.gc_next = NULL; /* object is not currently tracked */
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
static void
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_move(PyGC_Head *from, PyGC_Head *to)
|
|
|
|
|
{
|
2001-10-11 18:31:31 +00:00
|
|
|
if (from->gc.gc_next == from) {
|
2000-06-30 05:02:53 +00:00
|
|
|
/* empty from list */
|
|
|
|
|
gc_list_init(to);
|
2000-09-22 15:22:38 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2001-10-11 18:31:31 +00:00
|
|
|
to->gc.gc_next = from->gc.gc_next;
|
|
|
|
|
to->gc.gc_next->gc.gc_prev = to;
|
|
|
|
|
to->gc.gc_prev = from->gc.gc_prev;
|
|
|
|
|
to->gc.gc_prev->gc.gc_next = to;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
gc_list_init(from);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* append a list onto another list, from becomes an empty list */
|
|
|
|
|
static void
|
|
|
|
|
gc_list_merge(PyGC_Head *from, PyGC_Head *to)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *tail;
|
2001-10-11 18:31:31 +00:00
|
|
|
if (from->gc.gc_next != from) {
|
|
|
|
|
tail = to->gc.gc_prev;
|
|
|
|
|
tail->gc.gc_next = from->gc.gc_next;
|
|
|
|
|
tail->gc.gc_next->gc.gc_prev = tail;
|
|
|
|
|
to->gc.gc_prev = from->gc.gc_prev;
|
|
|
|
|
to->gc.gc_prev->gc.gc_next = to;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
gc_list_init(from);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static long
|
|
|
|
|
gc_list_size(PyGC_Head *list)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *gc;
|
|
|
|
|
long n = 0;
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = list->gc.gc_next; gc != list; gc = gc->gc.gc_next) {
|
2000-06-30 05:02:53 +00:00
|
|
|
n++;
|
|
|
|
|
}
|
|
|
|
|
return n;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*** end of list stuff ***/
|
|
|
|
|
|
|
|
|
|
|
2001-08-30 00:05:51 +00:00
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* Set all gc_refs = ob_refcnt. After this, STILL_A_CANDIDATE(o) is true
|
|
|
|
|
* for all objects in containers, and false for all tracked gc objects not
|
|
|
|
|
* in containers (although see the comment in visit_decref).
|
|
|
|
|
*/
|
2000-06-30 05:02:53 +00:00
|
|
|
static void
|
|
|
|
|
update_refs(PyGC_Head *containers)
|
|
|
|
|
{
|
2001-10-11 18:31:31 +00:00
|
|
|
PyGC_Head *gc = containers->gc.gc_next;
|
|
|
|
|
for (; gc != containers; gc=gc->gc.gc_next) {
|
|
|
|
|
gc->gc.gc_refs = FROM_GC(gc)->ob_refcnt;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
visit_decref(PyObject *op, void *data)
|
|
|
|
|
{
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* There's no point to decrementing gc_refs unless
|
|
|
|
|
* STILL_A_CANDIDATE(op) is true. It would take extra cycles to
|
|
|
|
|
* check that, though. If STILL_A_CANDIDATE(op) is false,
|
|
|
|
|
* decrementing gc_refs almost always makes it "even more negative",
|
|
|
|
|
* so doesn't change that STILL_A_CANDIDATE is false, and no harm is
|
|
|
|
|
* done. However, it's possible that, after many collections, this
|
|
|
|
|
* could underflow gc_refs in a long-lived old object. In that case,
|
|
|
|
|
* visit_move() may move the old object back to the generation
|
|
|
|
|
* getting collected. That would be a waste of time, but wouldn't
|
|
|
|
|
* cause an error.
|
|
|
|
|
*/
|
2000-06-30 05:02:53 +00:00
|
|
|
if (op && PyObject_IS_GC(op)) {
|
2001-08-30 00:05:51 +00:00
|
|
|
PyGC_Head *gc = AS_GC(op);
|
2001-10-11 18:31:31 +00:00
|
|
|
if (gc->gc.gc_next != NULL)
|
|
|
|
|
AS_GC(op)->gc.gc_refs--;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Subtract internal references from gc_refs */
|
|
|
|
|
static void
|
|
|
|
|
subtract_refs(PyGC_Head *containers)
|
|
|
|
|
{
|
|
|
|
|
traverseproc traverse;
|
2001-10-11 18:31:31 +00:00
|
|
|
PyGC_Head *gc = containers->gc.gc_next;
|
|
|
|
|
for (; gc != containers; gc=gc->gc.gc_next) {
|
2001-08-30 00:05:51 +00:00
|
|
|
traverse = FROM_GC(gc)->ob_type->tp_traverse;
|
|
|
|
|
(void) traverse(FROM_GC(gc),
|
2000-06-30 05:02:53 +00:00
|
|
|
(visitproc)visit_decref,
|
|
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* Move objects with gc_refs > 0 to roots list. They can't be collected. */
|
2000-06-30 05:02:53 +00:00
|
|
|
static void
|
|
|
|
|
move_roots(PyGC_Head *containers, PyGC_Head *roots)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *next;
|
2001-10-11 18:31:31 +00:00
|
|
|
PyGC_Head *gc = containers->gc.gc_next;
|
2000-06-30 05:02:53 +00:00
|
|
|
while (gc != containers) {
|
2001-10-11 18:31:31 +00:00
|
|
|
next = gc->gc.gc_next;
|
|
|
|
|
if (gc->gc.gc_refs > 0) {
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_remove(gc);
|
|
|
|
|
gc_list_append(gc, roots);
|
2001-10-11 18:31:31 +00:00
|
|
|
gc->gc.gc_refs = GC_MOVED;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
gc = next;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
2001-08-30 00:05:51 +00:00
|
|
|
visit_move(PyObject *op, PyGC_Head *tolist)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
|
|
|
|
if (PyObject_IS_GC(op)) {
|
2001-08-30 00:05:51 +00:00
|
|
|
PyGC_Head *gc = AS_GC(op);
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
if (gc->gc.gc_next != NULL && STILL_A_CANDIDATE(op)) {
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_remove(gc);
|
2001-08-30 00:05:51 +00:00
|
|
|
gc_list_append(gc, tolist);
|
2001-10-11 18:31:31 +00:00
|
|
|
gc->gc.gc_refs = GC_MOVED;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* Move candidates referenced from reachable to reachable set (they're no
|
|
|
|
|
* longer candidates).
|
|
|
|
|
*/
|
2000-06-30 05:02:53 +00:00
|
|
|
static void
|
|
|
|
|
move_root_reachable(PyGC_Head *reachable)
|
|
|
|
|
{
|
|
|
|
|
traverseproc traverse;
|
2001-10-11 18:31:31 +00:00
|
|
|
PyGC_Head *gc = reachable->gc.gc_next;
|
|
|
|
|
for (; gc != reachable; gc=gc->gc.gc_next) {
|
2000-06-30 05:02:53 +00:00
|
|
|
/* careful, reachable list is growing here */
|
2001-08-30 00:05:51 +00:00
|
|
|
PyObject *op = FROM_GC(gc);
|
2000-06-30 05:02:53 +00:00
|
|
|
traverse = op->ob_type->tp_traverse;
|
|
|
|
|
(void) traverse(op,
|
2001-08-30 00:05:51 +00:00
|
|
|
(visitproc)visit_move,
|
2000-06-30 05:02:53 +00:00
|
|
|
(void *)reachable);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2003-04-08 19:13:14 +00:00
|
|
|
/* Return true if object has a finalization method.
|
|
|
|
|
* CAUTION: class instances have to be checked for a __del__ method, and
|
|
|
|
|
* earlier versions of this used to call PyObject_HasAttr, which in turn
|
|
|
|
|
* could call the class's __getattr__ hook (if any). That could invoke
|
|
|
|
|
* arbitrary Python code, mutating the object graph in arbitrary ways, and
|
|
|
|
|
* that was the source of some excruciatingly subtle bugs.
|
|
|
|
|
*/
|
2001-11-01 17:35:23 +00:00
|
|
|
static int
|
|
|
|
|
has_finalizer(PyObject *op)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
2000-08-31 15:10:24 +00:00
|
|
|
static PyObject *delstr = NULL;
|
2000-06-30 05:02:53 +00:00
|
|
|
if (delstr == NULL) {
|
|
|
|
|
delstr = PyString_InternFromString("__del__");
|
2000-08-31 15:10:24 +00:00
|
|
|
if (delstr == NULL)
|
|
|
|
|
Py_FatalError("PyGC: can't initialize __del__ string");
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
2003-04-08 19:13:14 +00:00
|
|
|
|
|
|
|
|
if (PyInstance_Check(op))
|
|
|
|
|
return _PyInstance_Lookup(op, delstr) != NULL;
|
|
|
|
|
else if (PyType_HasFeature(op->ob_type, Py_TPFLAGS_HEAPTYPE))
|
2003-04-08 20:33:05 +00:00
|
|
|
return _PyType_Lookup(op->ob_type, delstr) != NULL;
|
2003-04-08 19:13:14 +00:00
|
|
|
else
|
|
|
|
|
return 0;
|
2001-11-01 17:35:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Move all objects with finalizers (instances with __del__) */
|
|
|
|
|
static void
|
|
|
|
|
move_finalizers(PyGC_Head *unreachable, PyGC_Head *finalizers)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *gc = unreachable->gc.gc_next;
|
2003-04-08 20:33:05 +00:00
|
|
|
|
|
|
|
|
while (gc != unreachable) {
|
|
|
|
|
PyGC_Head *next = gc->gc.gc_next;
|
2001-08-30 00:05:51 +00:00
|
|
|
PyObject *op = FROM_GC(gc);
|
2003-04-08 20:33:05 +00:00
|
|
|
|
2001-11-01 17:35:23 +00:00
|
|
|
if (has_finalizer(op)) {
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_remove(gc);
|
|
|
|
|
gc_list_append(gc, finalizers);
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
gc->gc.gc_refs = GC_MOVED;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
2003-04-08 20:33:05 +00:00
|
|
|
gc = next;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Move objects referenced from roots to roots */
|
|
|
|
|
static void
|
|
|
|
|
move_finalizer_reachable(PyGC_Head *finalizers)
|
|
|
|
|
{
|
|
|
|
|
traverseproc traverse;
|
2001-10-11 18:31:31 +00:00
|
|
|
PyGC_Head *gc = finalizers->gc.gc_next;
|
|
|
|
|
for (; gc != finalizers; gc=gc->gc.gc_next) {
|
2000-06-30 05:02:53 +00:00
|
|
|
/* careful, finalizers list is growing here */
|
2001-08-30 00:05:51 +00:00
|
|
|
traverse = FROM_GC(gc)->ob_type->tp_traverse;
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
(void) traverse(FROM_GC(gc),
|
2001-08-30 00:05:51 +00:00
|
|
|
(visitproc)visit_move,
|
2000-06-30 05:02:53 +00:00
|
|
|
(void *)finalizers);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2000-08-31 15:10:24 +00:00
|
|
|
debug_instance(char *msg, PyInstanceObject *inst)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
|
|
|
|
char *cname;
|
2001-11-01 17:35:23 +00:00
|
|
|
/* simple version of instance_repr */
|
2000-06-30 05:02:53 +00:00
|
|
|
PyObject *classname = inst->in_class->cl_name;
|
|
|
|
|
if (classname != NULL && PyString_Check(classname))
|
|
|
|
|
cname = PyString_AsString(classname);
|
|
|
|
|
else
|
|
|
|
|
cname = "?";
|
2000-08-31 15:10:24 +00:00
|
|
|
PySys_WriteStderr("gc: %.100s <%.100s instance at %p>\n",
|
|
|
|
|
msg, cname, inst);
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2000-08-31 15:10:24 +00:00
|
|
|
debug_cycle(char *msg, PyObject *op)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
|
|
|
|
if ((debug & DEBUG_INSTANCES) && PyInstance_Check(op)) {
|
2000-08-31 15:10:24 +00:00
|
|
|
debug_instance(msg, (PyInstanceObject *)op);
|
2000-09-22 15:22:38 +00:00
|
|
|
}
|
|
|
|
|
else if (debug & DEBUG_OBJECTS) {
|
2000-08-31 15:10:24 +00:00
|
|
|
PySys_WriteStderr("gc: %.100s <%.100s %p>\n",
|
|
|
|
|
msg, op->ob_type->tp_name, op);
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Handle uncollectable garbage (cycles with finalizers). */
|
|
|
|
|
static void
|
|
|
|
|
handle_finalizers(PyGC_Head *finalizers, PyGC_Head *old)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *gc;
|
|
|
|
|
if (garbage == NULL) {
|
|
|
|
|
garbage = PyList_New(0);
|
|
|
|
|
}
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = finalizers->gc.gc_next; gc != finalizers;
|
|
|
|
|
gc = finalizers->gc.gc_next) {
|
2001-08-30 00:05:51 +00:00
|
|
|
PyObject *op = FROM_GC(gc);
|
2001-11-01 17:35:23 +00:00
|
|
|
if ((debug & DEBUG_SAVEALL) || has_finalizer(op)) {
|
|
|
|
|
/* If SAVEALL is not set then just append objects with
|
|
|
|
|
* finalizers to the list of garbage. All objects in
|
|
|
|
|
* the finalizers list are reachable from those
|
|
|
|
|
* objects. */
|
2000-06-30 05:02:53 +00:00
|
|
|
PyList_Append(garbage, op);
|
|
|
|
|
}
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
/* object is now reachable again */
|
|
|
|
|
assert(!STILL_A_CANDIDATE(op));
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_remove(gc);
|
|
|
|
|
gc_list_append(gc, old);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2000-09-22 15:22:38 +00:00
|
|
|
/* Break reference cycles by clearing the containers involved. This is
|
2000-06-30 05:02:53 +00:00
|
|
|
* tricky business as the lists can be changing and we don't know which
|
|
|
|
|
* objects may be freed. It is possible I screwed something up here. */
|
|
|
|
|
static void
|
|
|
|
|
delete_garbage(PyGC_Head *unreachable, PyGC_Head *old)
|
|
|
|
|
{
|
|
|
|
|
inquiry clear;
|
|
|
|
|
|
2001-10-11 18:31:31 +00:00
|
|
|
while (unreachable->gc.gc_next != unreachable) {
|
|
|
|
|
PyGC_Head *gc = unreachable->gc.gc_next;
|
2001-08-30 00:05:51 +00:00
|
|
|
PyObject *op = FROM_GC(gc);
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
|
|
|
|
|
assert(STILL_A_CANDIDATE(op));
|
2000-09-22 15:22:38 +00:00
|
|
|
if (debug & DEBUG_SAVEALL) {
|
|
|
|
|
PyList_Append(garbage, op);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
if ((clear = op->ob_type->tp_clear) != NULL) {
|
|
|
|
|
Py_INCREF(op);
|
|
|
|
|
clear((PyObject *)op);
|
|
|
|
|
Py_DECREF(op);
|
|
|
|
|
}
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
2001-10-11 18:31:31 +00:00
|
|
|
if (unreachable->gc.gc_next == gc) {
|
2000-09-22 15:22:38 +00:00
|
|
|
/* object is still alive, move it, it may die later */
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_remove(gc);
|
|
|
|
|
gc_list_append(gc, old);
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
gc->gc.gc_refs = GC_MOVED;
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This is the main function. Read this to understand how the
|
|
|
|
|
* collection process works. */
|
|
|
|
|
static long
|
|
|
|
|
collect(PyGC_Head *young, PyGC_Head *old)
|
|
|
|
|
{
|
|
|
|
|
long n = 0;
|
|
|
|
|
long m = 0;
|
|
|
|
|
PyGC_Head reachable;
|
|
|
|
|
PyGC_Head unreachable;
|
|
|
|
|
PyGC_Head finalizers;
|
|
|
|
|
PyGC_Head *gc;
|
|
|
|
|
|
|
|
|
|
if (debug & DEBUG_STATS) {
|
2000-08-31 15:10:24 +00:00
|
|
|
PySys_WriteStderr(
|
|
|
|
|
"gc: collecting generation %d...\n"
|
|
|
|
|
"gc: objects in each generation: %ld %ld %ld\n",
|
|
|
|
|
generation,
|
2001-08-30 00:05:51 +00:00
|
|
|
gc_list_size(&_PyGC_generation0),
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_size(&generation1),
|
|
|
|
|
gc_list_size(&generation2));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Using ob_refcnt and gc_refs, calculate which objects in the
|
|
|
|
|
* container set are reachable from outside the set (ie. have a
|
|
|
|
|
* refcount greater than 0 when all the references within the
|
|
|
|
|
* set are taken into account */
|
|
|
|
|
update_refs(young);
|
|
|
|
|
subtract_refs(young);
|
|
|
|
|
|
|
|
|
|
/* Move everything reachable from outside the set into the
|
|
|
|
|
* reachable set (ie. gc_refs > 0). Next, move everything
|
|
|
|
|
* reachable from objects in the reachable set. */
|
|
|
|
|
gc_list_init(&reachable);
|
|
|
|
|
move_roots(young, &reachable);
|
|
|
|
|
move_root_reachable(&reachable);
|
|
|
|
|
|
|
|
|
|
/* move unreachable objects to a temporary list, new objects can be
|
|
|
|
|
* allocated after this point */
|
|
|
|
|
gc_list_init(&unreachable);
|
|
|
|
|
gc_list_move(young, &unreachable);
|
|
|
|
|
|
|
|
|
|
/* move reachable objects to next generation */
|
|
|
|
|
gc_list_merge(&reachable, old);
|
|
|
|
|
|
|
|
|
|
/* Move objects reachable from finalizers, we can't safely delete
|
|
|
|
|
* them. Python programmers should take care not to create such
|
|
|
|
|
* things. For Python finalizers means instance objects with
|
|
|
|
|
* __del__ methods. */
|
|
|
|
|
gc_list_init(&finalizers);
|
|
|
|
|
move_finalizers(&unreachable, &finalizers);
|
|
|
|
|
move_finalizer_reachable(&finalizers);
|
|
|
|
|
|
|
|
|
|
/* Collect statistics on collectable objects found and print
|
|
|
|
|
* debugging information. */
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = unreachable.gc.gc_next; gc != &unreachable;
|
|
|
|
|
gc = gc->gc.gc_next) {
|
2000-06-30 05:02:53 +00:00
|
|
|
m++;
|
2000-08-31 15:10:24 +00:00
|
|
|
if (debug & DEBUG_COLLECTABLE) {
|
2001-08-30 00:05:51 +00:00
|
|
|
debug_cycle("collectable", FROM_GC(gc));
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* call tp_clear on objects in the collectable set. This will cause
|
|
|
|
|
* the reference cycles to be broken. It may also cause some objects in
|
|
|
|
|
* finalizers to be freed */
|
|
|
|
|
delete_garbage(&unreachable, old);
|
|
|
|
|
|
|
|
|
|
/* Collect statistics on uncollectable objects found and print
|
|
|
|
|
* debugging information. */
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = finalizers.gc.gc_next; gc != &finalizers;
|
|
|
|
|
gc = gc->gc.gc_next) {
|
2000-06-30 05:02:53 +00:00
|
|
|
n++;
|
2000-08-31 15:10:24 +00:00
|
|
|
if (debug & DEBUG_UNCOLLECTABLE) {
|
2001-08-30 00:05:51 +00:00
|
|
|
debug_cycle("uncollectable", FROM_GC(gc));
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
2000-08-31 15:10:24 +00:00
|
|
|
if (debug & DEBUG_STATS) {
|
2000-06-30 05:02:53 +00:00
|
|
|
if (m == 0 && n == 0) {
|
2000-08-31 15:10:24 +00:00
|
|
|
PySys_WriteStderr("gc: done.\n");
|
2000-09-22 15:22:38 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2000-08-31 15:10:24 +00:00
|
|
|
PySys_WriteStderr(
|
|
|
|
|
"gc: done, %ld unreachable, %ld uncollectable.\n",
|
|
|
|
|
n+m, n);
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Append instances in the uncollectable set to a Python
|
|
|
|
|
* reachable list of garbage. The programmer has to deal with
|
|
|
|
|
* this if they insist on creating this type of structure. */
|
|
|
|
|
handle_finalizers(&finalizers, old);
|
|
|
|
|
|
2000-09-01 02:47:25 +00:00
|
|
|
if (PyErr_Occurred()) {
|
2000-09-22 15:22:38 +00:00
|
|
|
if (gc_str == NULL) {
|
|
|
|
|
gc_str = PyString_FromString("garbage collection");
|
|
|
|
|
}
|
2000-09-01 02:47:25 +00:00
|
|
|
PyErr_WriteUnraisable(gc_str);
|
|
|
|
|
Py_FatalError("unexpected exception during garbage collection");
|
|
|
|
|
}
|
2000-06-30 05:02:53 +00:00
|
|
|
allocated = 0;
|
|
|
|
|
return n+m;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static long
|
|
|
|
|
collect_generations(void)
|
|
|
|
|
{
|
|
|
|
|
static long collections0 = 0;
|
|
|
|
|
static long collections1 = 0;
|
2000-07-10 05:37:39 +00:00
|
|
|
long n = 0;
|
2000-06-30 05:02:53 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
if (collections1 > threshold2) {
|
|
|
|
|
generation = 2;
|
2001-08-30 00:05:51 +00:00
|
|
|
gc_list_merge(&_PyGC_generation0, &generation2);
|
2000-06-30 05:02:53 +00:00
|
|
|
gc_list_merge(&generation1, &generation2);
|
2001-10-11 18:31:31 +00:00
|
|
|
if (generation2.gc.gc_next != &generation2) {
|
2000-06-30 05:02:53 +00:00
|
|
|
n = collect(&generation2, &generation2);
|
|
|
|
|
}
|
|
|
|
|
collections1 = 0;
|
2000-09-22 15:22:38 +00:00
|
|
|
}
|
|
|
|
|
else if (collections0 > threshold1) {
|
2000-06-30 05:02:53 +00:00
|
|
|
generation = 1;
|
|
|
|
|
collections1++;
|
2001-08-30 00:05:51 +00:00
|
|
|
gc_list_merge(&_PyGC_generation0, &generation1);
|
2001-10-11 18:31:31 +00:00
|
|
|
if (generation1.gc.gc_next != &generation1) {
|
2000-06-30 05:02:53 +00:00
|
|
|
n = collect(&generation1, &generation2);
|
|
|
|
|
}
|
|
|
|
|
collections0 = 0;
|
2000-09-22 15:22:38 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2000-06-30 05:02:53 +00:00
|
|
|
generation = 0;
|
|
|
|
|
collections0++;
|
2001-10-11 18:31:31 +00:00
|
|
|
if (_PyGC_generation0.gc.gc_next != &_PyGC_generation0) {
|
2001-08-30 00:05:51 +00:00
|
|
|
n = collect(&_PyGC_generation0, &generation1);
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return n;
|
|
|
|
|
}
|
|
|
|
|
|
2000-08-06 22:45:31 +00:00
|
|
|
static char gc_enable__doc__[] =
|
|
|
|
|
"enable() -> None\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Enable automatic garbage collection.\n"
|
|
|
|
|
;
|
2000-06-30 05:02:53 +00:00
|
|
|
|
2000-08-06 22:45:31 +00:00
|
|
|
static PyObject *
|
|
|
|
|
gc_enable(PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple(args, ":enable")) /* check no args */
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
enabled = 1;
|
|
|
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
|
return Py_None;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char gc_disable__doc__[] =
|
|
|
|
|
"disable() -> None\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Disable automatic garbage collection.\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
gc_disable(PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple(args, ":disable")) /* check no args */
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
enabled = 0;
|
|
|
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
|
return Py_None;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char gc_isenabled__doc__[] =
|
|
|
|
|
"isenabled() -> status\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Returns true if automatic garbage collection is enabled.\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
gc_isenabled(PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple(args, ":isenabled")) /* check no args */
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return Py_BuildValue("i", enabled);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char gc_collect__doc__[] =
|
2000-06-30 05:02:53 +00:00
|
|
|
"collect() -> n\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Run a full collection. The number of unreachable objects is returned.\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 22:45:31 +00:00
|
|
|
gc_collect(PyObject *self, PyObject *args)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
|
|
|
|
long n;
|
|
|
|
|
|
2000-07-12 04:42:23 +00:00
|
|
|
if (!PyArg_ParseTuple(args, ":collect")) /* check no args */
|
2000-06-30 05:02:53 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
2001-10-31 23:09:35 +00:00
|
|
|
if (collecting) {
|
|
|
|
|
n = 0; /* already collecting, don't do anything */
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
collecting = 1;
|
|
|
|
|
generation = 2;
|
|
|
|
|
gc_list_merge(&_PyGC_generation0, &generation2);
|
|
|
|
|
gc_list_merge(&generation1, &generation2);
|
|
|
|
|
n = collect(&generation2, &generation2);
|
|
|
|
|
collecting = 0;
|
|
|
|
|
}
|
2000-06-30 05:02:53 +00:00
|
|
|
|
2000-09-22 22:35:36 +00:00
|
|
|
return Py_BuildValue("l", n);
|
2000-06-30 05:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
static char gc_set_debug__doc__[] =
|
2000-06-30 05:02:53 +00:00
|
|
|
"set_debug(flags) -> None\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Set the garbage collection debugging flags. Debugging information is\n"
|
|
|
|
|
"written to sys.stderr.\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"flags is an integer and can have the following bits turned on:\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" DEBUG_STATS - Print statistics during collection.\n"
|
|
|
|
|
" DEBUG_COLLECTABLE - Print collectable objects found.\n"
|
|
|
|
|
" DEBUG_UNCOLLECTABLE - Print unreachable but uncollectable objects found.\n"
|
|
|
|
|
" DEBUG_INSTANCES - Print instance objects.\n"
|
|
|
|
|
" DEBUG_OBJECTS - Print objects other than instances.\n"
|
2000-09-22 15:22:38 +00:00
|
|
|
" DEBUG_SAVEALL - Save objects to gc.garbage rather than freeing them.\n"
|
2000-06-30 05:02:53 +00:00
|
|
|
" DEBUG_LEAK - Debug leaking programs (everything but STATS).\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 22:45:31 +00:00
|
|
|
gc_set_debug(PyObject *self, PyObject *args)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
2000-09-22 22:35:36 +00:00
|
|
|
if (!PyArg_ParseTuple(args, "i:set_debug", &debug))
|
2000-06-30 05:02:53 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
|
return Py_None;
|
|
|
|
|
}
|
|
|
|
|
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
static char gc_get_debug__doc__[] =
|
2000-06-30 05:02:53 +00:00
|
|
|
"get_debug() -> flags\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Get the garbage collection debugging flags.\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 22:45:31 +00:00
|
|
|
gc_get_debug(PyObject *self, PyObject *args)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
2000-07-12 04:42:23 +00:00
|
|
|
if (!PyArg_ParseTuple(args, ":get_debug")) /* no args */
|
2000-06-30 05:02:53 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return Py_BuildValue("i", debug);
|
|
|
|
|
}
|
|
|
|
|
|
2000-08-06 22:45:31 +00:00
|
|
|
static char gc_set_thresh__doc__[] =
|
2002-02-06 17:06:03 +00:00
|
|
|
"set_threshold(threshold0, [threshold1, threshold2]) -> None\n"
|
2000-06-30 05:02:53 +00:00
|
|
|
"\n"
|
|
|
|
|
"Sets the collection thresholds. Setting threshold0 to zero disables\n"
|
|
|
|
|
"collection.\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 22:45:31 +00:00
|
|
|
gc_set_thresh(PyObject *self, PyObject *args)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
Backport for SF bug #574132: Major GC related performance regression.
2.2.1 has another bug that prevents the regression (which isn't a
regression at all) from showing up. "The regression" is actually a
glitch in cyclic gc that's been there forever.
As the generation being collected is analyzed, objects that can't be
collected (because, e.g., we find they're externally referenced, or
are in an unreachable cycle but have a __del__ method) are moved out
of the list of candidates. A tricksy scheme uses negative values of
gc_refs to mark such objects as being moved. However, the exact
negative value set at the start may become "more negative" over time
for objects not in the generation being collected, and the scheme was
checking for an exact match on the negative value originally assigned.
As a result, objects in generations older than the one being collected
could get scanned too, and yanked back into a younger generation. Doing
so doesn't lead to an error, but doesn't do any good, and can burn an
unbounded amount of time doing useless work.
A test case is simple (thanks to Kevin Jacobs for finding it!):
x = []
for i in xrange(200000):
x.append((1,))
Without the patch, this ends up scanning all of x on every gen0 collection,
scans all of x twice on every gen1 collection, and x gets yanked back into
gen1 on every gen0 collection. With the patch, once x gets to gen2, it's
never scanned again until another gen2 collection, and stays in gen2.
Opened another bug about that 2.2.1 isn't actually tracking (at least)
iterators, generators, and bound method objects, due to using the 2.1
gc API internally in those places (which #defines itself out of existence
in 2.2.x).
2002-06-30 18:48:53 +00:00
|
|
|
if (!PyArg_ParseTuple(args, "i|ii:set_threshold", &threshold0,
|
2000-06-30 05:02:53 +00:00
|
|
|
&threshold1, &threshold2))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
|
return Py_None;
|
|
|
|
|
}
|
|
|
|
|
|
2000-08-06 22:45:31 +00:00
|
|
|
static char gc_get_thresh__doc__[] =
|
2000-06-30 05:02:53 +00:00
|
|
|
"get_threshold() -> (threshold0, threshold1, threshold2)\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Return the current collection thresholds\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 22:45:31 +00:00
|
|
|
gc_get_thresh(PyObject *self, PyObject *args)
|
2000-06-30 05:02:53 +00:00
|
|
|
{
|
2000-07-12 04:42:23 +00:00
|
|
|
if (!PyArg_ParseTuple(args, ":get_threshold")) /* no args */
|
2000-06-30 05:02:53 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return Py_BuildValue("(iii)", threshold0, threshold1, threshold2);
|
|
|
|
|
}
|
|
|
|
|
|
2001-08-09 15:38:31 +00:00
|
|
|
static int
|
2001-11-24 09:24:51 +00:00
|
|
|
referrersvisit(PyObject* obj, PyObject *objs)
|
2001-08-09 15:38:31 +00:00
|
|
|
{
|
2001-11-29 18:08:31 +00:00
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < PyTuple_GET_SIZE(objs); i++)
|
|
|
|
|
if (PyTuple_GET_ITEM(objs, i) == obj)
|
|
|
|
|
return 1;
|
2001-08-09 15:38:31 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2001-08-10 14:46:47 +00:00
|
|
|
static int
|
2001-11-24 09:24:51 +00:00
|
|
|
gc_referrers_for(PyObject *objs, PyGC_Head *list, PyObject *resultlist)
|
2001-08-09 15:38:31 +00:00
|
|
|
{
|
|
|
|
|
PyGC_Head *gc;
|
|
|
|
|
PyObject *obj;
|
|
|
|
|
traverseproc traverse;
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = list->gc.gc_next; gc != list; gc = gc->gc.gc_next) {
|
2001-08-30 00:05:51 +00:00
|
|
|
obj = FROM_GC(gc);
|
2001-08-09 15:38:31 +00:00
|
|
|
traverse = obj->ob_type->tp_traverse;
|
|
|
|
|
if (obj == objs || obj == resultlist)
|
|
|
|
|
continue;
|
2001-11-24 09:24:51 +00:00
|
|
|
if (traverse(obj, (visitproc)referrersvisit, objs)) {
|
2001-08-10 14:46:47 +00:00
|
|
|
if (PyList_Append(resultlist, obj) < 0)
|
|
|
|
|
return 0; /* error */
|
2001-08-09 15:38:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
2001-08-10 14:46:47 +00:00
|
|
|
return 1; /* no error */
|
2001-08-09 15:38:31 +00:00
|
|
|
}
|
|
|
|
|
|
2001-11-24 09:24:51 +00:00
|
|
|
static char gc_get_referrers__doc__[]=
|
|
|
|
|
"get_referrers(*objs) -> list\n\
|
2001-08-09 15:38:31 +00:00
|
|
|
Return the list of objects that directly refer to any of objs.";
|
|
|
|
|
|
2001-08-10 14:46:47 +00:00
|
|
|
static PyObject *
|
2001-11-24 09:24:51 +00:00
|
|
|
gc_get_referrers(PyObject *self, PyObject *args)
|
2001-08-09 15:38:31 +00:00
|
|
|
{
|
|
|
|
|
PyObject *result = PyList_New(0);
|
2001-11-24 09:24:51 +00:00
|
|
|
if (!(gc_referrers_for(args, &_PyGC_generation0, result) &&
|
|
|
|
|
gc_referrers_for(args, &generation1, result) &&
|
|
|
|
|
gc_referrers_for(args, &generation2, result))) {
|
2001-08-10 14:46:47 +00:00
|
|
|
Py_DECREF(result);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2001-08-09 15:38:31 +00:00
|
|
|
return result;
|
|
|
|
|
}
|
2000-06-30 05:02:53 +00:00
|
|
|
|
2001-08-09 15:58:59 +00:00
|
|
|
static char gc_get_objects__doc__[] =
|
|
|
|
|
"get_objects() -> [...]\n"
|
|
|
|
|
"\n"
|
|
|
|
|
"Return a list of objects tracked by the collector (excluding the list\n"
|
|
|
|
|
"returned).\n"
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
/* appending objects in a GC list to a Python list */
|
2001-12-02 12:21:34 +00:00
|
|
|
static int
|
2001-08-09 15:58:59 +00:00
|
|
|
append_objects(PyObject *py_list, PyGC_Head *gc_list)
|
|
|
|
|
{
|
|
|
|
|
PyGC_Head *gc;
|
2001-10-11 18:31:31 +00:00
|
|
|
for (gc = gc_list->gc.gc_next; gc != gc_list; gc = gc->gc.gc_next) {
|
2001-08-30 00:05:51 +00:00
|
|
|
PyObject *op = FROM_GC(gc);
|
2001-08-09 15:58:59 +00:00
|
|
|
if (op != py_list) {
|
2001-12-02 12:21:34 +00:00
|
|
|
if (PyList_Append(py_list, op)) {
|
|
|
|
|
return -1; /* exception */
|
|
|
|
|
}
|
2001-08-09 15:58:59 +00:00
|
|
|
}
|
|
|
|
|
}
|
2001-12-02 12:21:34 +00:00
|
|
|
return 0;
|
2001-08-09 15:58:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
gc_get_objects(PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
PyObject* result;
|
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple(args, ":get_objects")) /* check no args */
|
|
|
|
|
return NULL;
|
|
|
|
|
result = PyList_New(0);
|
2001-12-02 18:31:02 +00:00
|
|
|
if (result == NULL) {
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2001-12-02 12:21:34 +00:00
|
|
|
if (append_objects(result, &_PyGC_generation0) ||
|
|
|
|
|
append_objects(result, &generation1) ||
|
|
|
|
|
append_objects(result, &generation2)) {
|
|
|
|
|
Py_DECREF(result);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2001-08-09 15:58:59 +00:00
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
static char gc__doc__ [] =
|
|
|
|
|
"This module provides access to the garbage collector for reference cycles.\n"
|
|
|
|
|
"\n"
|
2000-08-06 22:45:31 +00:00
|
|
|
"enable() -- Enable automatic garbage collection.\n"
|
|
|
|
|
"disable() -- Disable automatic garbage collection.\n"
|
|
|
|
|
"isenabled() -- Returns true if automatic collection is enabled.\n"
|
2000-06-30 05:02:53 +00:00
|
|
|
"collect() -- Do a full collection right now.\n"
|
|
|
|
|
"set_debug() -- Set debugging flags.\n"
|
|
|
|
|
"get_debug() -- Get debugging flags.\n"
|
|
|
|
|
"set_threshold() -- Set the collection thresholds.\n"
|
|
|
|
|
"get_threshold() -- Return the current the collection thresholds.\n"
|
2001-08-09 15:58:59 +00:00
|
|
|
"get_objects() -- Return a list of all objects tracked by the collector.\n"
|
2001-11-24 09:24:51 +00:00
|
|
|
"get_referrers() -- Return the list of objects that refer to an object.\n"
|
2000-06-30 05:02:53 +00:00
|
|
|
;
|
|
|
|
|
|
|
|
|
|
static PyMethodDef GcMethods[] = {
|
2000-09-22 15:22:38 +00:00
|
|
|
{"enable", gc_enable, METH_VARARGS, gc_enable__doc__},
|
|
|
|
|
{"disable", gc_disable, METH_VARARGS, gc_disable__doc__},
|
2000-08-06 22:45:31 +00:00
|
|
|
{"isenabled", gc_isenabled, METH_VARARGS, gc_isenabled__doc__},
|
|
|
|
|
{"set_debug", gc_set_debug, METH_VARARGS, gc_set_debug__doc__},
|
|
|
|
|
{"get_debug", gc_get_debug, METH_VARARGS, gc_get_debug__doc__},
|
|
|
|
|
{"set_threshold", gc_set_thresh, METH_VARARGS, gc_set_thresh__doc__},
|
|
|
|
|
{"get_threshold", gc_get_thresh, METH_VARARGS, gc_get_thresh__doc__},
|
2000-09-22 15:22:38 +00:00
|
|
|
{"collect", gc_collect, METH_VARARGS, gc_collect__doc__},
|
2001-08-09 15:58:59 +00:00
|
|
|
{"get_objects", gc_get_objects,METH_VARARGS, gc_get_objects__doc__},
|
2001-11-24 09:24:51 +00:00
|
|
|
{"get_referrers", gc_get_referrers, METH_VARARGS,
|
|
|
|
|
gc_get_referrers__doc__},
|
2000-06-30 05:02:53 +00:00
|
|
|
{NULL, NULL} /* Sentinel */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
initgc(void)
|
|
|
|
|
{
|
|
|
|
|
PyObject *m;
|
|
|
|
|
PyObject *d;
|
|
|
|
|
|
|
|
|
|
m = Py_InitModule4("gc",
|
|
|
|
|
GcMethods,
|
|
|
|
|
gc__doc__,
|
|
|
|
|
NULL,
|
|
|
|
|
PYTHON_API_VERSION);
|
|
|
|
|
d = PyModule_GetDict(m);
|
|
|
|
|
if (garbage == NULL) {
|
|
|
|
|
garbage = PyList_New(0);
|
|
|
|
|
}
|
|
|
|
|
PyDict_SetItemString(d, "garbage", garbage);
|
|
|
|
|
PyDict_SetItemString(d, "DEBUG_STATS",
|
|
|
|
|
PyInt_FromLong(DEBUG_STATS));
|
|
|
|
|
PyDict_SetItemString(d, "DEBUG_COLLECTABLE",
|
|
|
|
|
PyInt_FromLong(DEBUG_COLLECTABLE));
|
|
|
|
|
PyDict_SetItemString(d, "DEBUG_UNCOLLECTABLE",
|
|
|
|
|
PyInt_FromLong(DEBUG_UNCOLLECTABLE));
|
|
|
|
|
PyDict_SetItemString(d, "DEBUG_INSTANCES",
|
|
|
|
|
PyInt_FromLong(DEBUG_INSTANCES));
|
|
|
|
|
PyDict_SetItemString(d, "DEBUG_OBJECTS",
|
|
|
|
|
PyInt_FromLong(DEBUG_OBJECTS));
|
2000-09-22 15:22:38 +00:00
|
|
|
PyDict_SetItemString(d, "DEBUG_SAVEALL",
|
|
|
|
|
PyInt_FromLong(DEBUG_SAVEALL));
|
2000-06-30 05:02:53 +00:00
|
|
|
PyDict_SetItemString(d, "DEBUG_LEAK",
|
|
|
|
|
PyInt_FromLong(DEBUG_LEAK));
|
|
|
|
|
}
|
|
|
|
|
|
2001-08-30 00:05:51 +00:00
|
|
|
/* for debugging */
|
|
|
|
|
void _PyGC_Dump(PyGC_Head *g)
|
|
|
|
|
{
|
|
|
|
|
_PyObject_Dump(FROM_GC(g));
|
|
|
|
|
}
|
|
|
|
|
|
2000-06-30 05:02:53 +00:00
|
|
|
#endif /* WITH_CYCLE_GC */
|
2001-08-30 00:05:51 +00:00
|
|
|
|
|
|
|
|
/* extension modules might be compiled with GC support so these
|
|
|
|
|
functions must always be available */
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
_PyObject_GC_Track(PyObject *op)
|
|
|
|
|
{
|
|
|
|
|
_PyObject_GC_TRACK(op);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
_PyObject_GC_UnTrack(PyObject *op)
|
|
|
|
|
{
|
2002-04-03 14:07:32 +00:00
|
|
|
#ifdef WITH_CYCLE_GC
|
2002-03-28 20:36:50 +00:00
|
|
|
PyGC_Head *gc = AS_GC(op);
|
|
|
|
|
if (gc->gc.gc_next != NULL)
|
|
|
|
|
_PyObject_GC_UNTRACK(op);
|
2002-04-03 14:07:32 +00:00
|
|
|
#endif
|
2001-08-30 00:05:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PyObject *
|
2001-10-06 21:27:34 +00:00
|
|
|
_PyObject_GC_Malloc(PyTypeObject *tp, int nitems)
|
2001-08-30 00:05:51 +00:00
|
|
|
{
|
|
|
|
|
PyObject *op;
|
2001-10-07 03:54:51 +00:00
|
|
|
const size_t basicsize = _PyObject_VAR_SIZE(tp, nitems);
|
2001-08-30 00:05:51 +00:00
|
|
|
#ifdef WITH_CYCLE_GC
|
2001-10-07 03:54:51 +00:00
|
|
|
const size_t nbytes = sizeof(PyGC_Head) + basicsize;
|
|
|
|
|
PyGC_Head *g = PyObject_MALLOC(nbytes);
|
2001-08-30 00:05:51 +00:00
|
|
|
if (g == NULL)
|
|
|
|
|
return (PyObject *)PyErr_NoMemory();
|
2001-10-11 18:31:31 +00:00
|
|
|
g->gc.gc_next = NULL;
|
2001-08-30 00:05:51 +00:00
|
|
|
allocated++;
|
|
|
|
|
if (allocated > threshold0 &&
|
|
|
|
|
enabled &&
|
|
|
|
|
threshold0 &&
|
|
|
|
|
!collecting &&
|
|
|
|
|
!PyErr_Occurred()) {
|
|
|
|
|
collecting = 1;
|
|
|
|
|
collect_generations();
|
|
|
|
|
collecting = 0;
|
|
|
|
|
}
|
|
|
|
|
op = FROM_GC(g);
|
|
|
|
|
#else
|
2001-10-06 21:27:34 +00:00
|
|
|
op = PyObject_MALLOC(basicsize);
|
2001-08-30 00:05:51 +00:00
|
|
|
if (op == NULL)
|
|
|
|
|
return (PyObject *)PyErr_NoMemory();
|
|
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
return op;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
|
_PyObject_GC_New(PyTypeObject *tp)
|
|
|
|
|
{
|
2001-10-06 21:27:34 +00:00
|
|
|
PyObject *op = _PyObject_GC_Malloc(tp, 0);
|
2002-04-30 03:33:15 +00:00
|
|
|
if (op != NULL)
|
|
|
|
|
op = PyObject_INIT(op, tp);
|
|
|
|
|
return op;
|
2001-08-30 00:05:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PyVarObject *
|
2001-10-06 21:27:34 +00:00
|
|
|
_PyObject_GC_NewVar(PyTypeObject *tp, int nitems)
|
2001-08-30 00:05:51 +00:00
|
|
|
{
|
2001-10-06 21:27:34 +00:00
|
|
|
PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(tp, nitems);
|
2002-04-30 03:33:15 +00:00
|
|
|
if (op != NULL)
|
|
|
|
|
op = PyObject_INIT_VAR(op, tp, nitems);
|
|
|
|
|
return op;
|
2001-08-30 00:05:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PyVarObject *
|
2001-10-06 21:27:34 +00:00
|
|
|
_PyObject_GC_Resize(PyVarObject *op, int nitems)
|
2001-08-30 00:05:51 +00:00
|
|
|
{
|
2001-10-07 03:54:51 +00:00
|
|
|
const size_t basicsize = _PyObject_VAR_SIZE(op->ob_type, nitems);
|
2001-08-30 00:05:51 +00:00
|
|
|
#ifdef WITH_CYCLE_GC
|
|
|
|
|
PyGC_Head *g = AS_GC(op);
|
2001-10-06 21:27:34 +00:00
|
|
|
g = PyObject_REALLOC(g, sizeof(PyGC_Head) + basicsize);
|
2001-08-30 00:05:51 +00:00
|
|
|
if (g == NULL)
|
|
|
|
|
return (PyVarObject *)PyErr_NoMemory();
|
|
|
|
|
op = (PyVarObject *) FROM_GC(g);
|
|
|
|
|
#else
|
2001-10-06 21:27:34 +00:00
|
|
|
op = PyObject_REALLOC(op, basicsize);
|
2001-08-30 00:05:51 +00:00
|
|
|
if (op == NULL)
|
|
|
|
|
return (PyVarObject *)PyErr_NoMemory();
|
|
|
|
|
#endif
|
2001-10-06 21:27:34 +00:00
|
|
|
op->ob_size = nitems;
|
2001-08-30 00:05:51 +00:00
|
|
|
return op;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
_PyObject_GC_Del(PyObject *op)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WITH_CYCLE_GC
|
|
|
|
|
PyGC_Head *g = AS_GC(op);
|
2001-10-11 18:31:31 +00:00
|
|
|
if (g->gc.gc_next != NULL)
|
2001-08-30 00:05:51 +00:00
|
|
|
gc_list_remove(g);
|
|
|
|
|
if (allocated > 0) {
|
|
|
|
|
allocated--;
|
|
|
|
|
}
|
|
|
|
|
PyObject_FREE(g);
|
|
|
|
|
#else
|
|
|
|
|
PyObject_FREE(op);
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|