2000-06-30 02:02:53 -03:00
|
|
|
/*
|
SF bug #574132: Major GC related performance regression
"The regression" is actually due to that 2.2.1 had a bug that prevented
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.
Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand. 2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).
2002-06-30 14:56:40 -03:00
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
Reference Cycle Garbage Collection
|
|
|
|
==================================
|
|
|
|
|
2000-10-04 13:34:09 -03:00
|
|
|
Neil Schemenauer <nas@arctrix.com>
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
Based on a post on the python-dev list. Ideas from Guido van Rossum,
|
|
|
|
Eric Tiedemann, and various others.
|
|
|
|
|
2001-08-29 21:05:51 -03:00
|
|
|
http://www.arctrix.com/nas/python/gc/
|
2000-06-30 02:02:53 -03: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"
|
|
|
|
|
2001-08-29 21:05:51 -03: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 02:02:53 -03:00
|
|
|
/*** Global GC state ***/
|
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
struct gc_generation {
|
|
|
|
PyGC_Head head;
|
|
|
|
int threshold; /* collection threshold */
|
|
|
|
int count; /* count of allocations or collections of younger
|
|
|
|
generations */
|
|
|
|
};
|
|
|
|
|
|
|
|
#define NUM_GENERATIONS 3
|
|
|
|
#define GEN_HEAD(n) (&generations[n].head)
|
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
/* linked lists of container objects */
|
2002-05-04 02:35:20 -03:00
|
|
|
static struct gc_generation generations[NUM_GENERATIONS] = {
|
|
|
|
/* PyGC_Head, threshold, count */
|
|
|
|
{{{GEN_HEAD(0), GEN_HEAD(0), 0}}, 700, 0},
|
|
|
|
{{{GEN_HEAD(1), GEN_HEAD(1), 0}}, 10, 0},
|
|
|
|
{{{GEN_HEAD(2), GEN_HEAD(2), 0}}, 10, 0},
|
|
|
|
};
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
PyGC_Head *_PyGC_generation0 = GEN_HEAD(0);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
static int enabled = 1; /* automatic collection enabled? */
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2001-08-29 21:05:51 -03:00
|
|
|
/* true if we are currently running the collector */
|
2003-04-05 20:11:39 -04:00
|
|
|
static int collecting = 0;
|
2001-08-29 21:05:51 -03:00
|
|
|
|
2002-07-02 15:12:35 -03:00
|
|
|
/* list of uncollectable objects */
|
2003-04-05 20:11:39 -04:00
|
|
|
static PyObject *garbage = NULL;
|
2002-07-02 15:12:35 -03:00
|
|
|
|
|
|
|
/* Python string to use if unhandled exception occurs */
|
2003-04-05 20:11:39 -04:00
|
|
|
static PyObject *gc_str = NULL;
|
2002-07-02 15:12:35 -03:00
|
|
|
|
2003-04-05 13:15:44 -04:00
|
|
|
/* Python string used to look for __del__ attribute. */
|
|
|
|
static PyObject *delstr = NULL;
|
2003-04-04 15:59:06 -04:00
|
|
|
|
2000-06-30 02:02:53 -03: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 12:22:38 -03:00
|
|
|
#define DEBUG_SAVEALL (1<<5) /* save all garbage in gc.garbage */
|
2000-06-30 02:02:53 -03:00
|
|
|
#define DEBUG_LEAK DEBUG_COLLECTABLE | \
|
|
|
|
DEBUG_UNCOLLECTABLE | \
|
|
|
|
DEBUG_INSTANCES | \
|
2000-09-22 12:22:38 -03:00
|
|
|
DEBUG_OBJECTS | \
|
|
|
|
DEBUG_SAVEALL
|
2000-08-31 23:47:25 -03:00
|
|
|
static int debug;
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-07-02 15:12:35 -03:00
|
|
|
/*--------------------------------------------------------------------------
|
|
|
|
gc_refs values.
|
|
|
|
|
|
|
|
Between collections, every gc'ed object has one of two gc_refs values:
|
|
|
|
|
|
|
|
GC_UNTRACKED
|
|
|
|
The initial state; objects returned by PyObject_GC_Malloc are in this
|
|
|
|
state. The object doesn't live in any generation list, and its
|
|
|
|
tp_traverse slot must not be called.
|
|
|
|
|
|
|
|
GC_REACHABLE
|
|
|
|
The object lives in some generation list, and its tp_traverse is safe to
|
|
|
|
call. An object transitions to GC_REACHABLE when PyObject_GC_Track
|
|
|
|
is called.
|
|
|
|
|
|
|
|
During a collection, gc_refs can temporarily take on other states:
|
|
|
|
|
|
|
|
>= 0
|
|
|
|
At the start of a collection, update_refs() copies the true refcount
|
|
|
|
to gc_refs, for each object in the generation being collected.
|
|
|
|
subtract_refs() then adjusts gc_refs so that it equals the number of
|
|
|
|
times an object is referenced directly from outside the generation
|
|
|
|
being collected.
|
2002-11-09 15:54:06 -04:00
|
|
|
gc_refs remains >= 0 throughout these steps.
|
2002-07-02 15:12:35 -03:00
|
|
|
|
|
|
|
GC_TENTATIVELY_UNREACHABLE
|
|
|
|
move_unreachable() then moves objects not reachable (whether directly or
|
|
|
|
indirectly) from outside the generation into an "unreachable" set.
|
|
|
|
Objects that are found to be reachable have gc_refs set to GC_REACHABLE
|
|
|
|
again. Objects that are found to be unreachable have gc_refs set to
|
|
|
|
GC_TENTATIVELY_UNREACHABLE. It's "tentatively" because the pass doing
|
|
|
|
this can't be sure until it ends, and GC_TENTATIVELY_UNREACHABLE may
|
|
|
|
transition back to GC_REACHABLE.
|
|
|
|
|
|
|
|
Only objects with GC_TENTATIVELY_UNREACHABLE still set are candidates
|
|
|
|
for collection. If it's decided not to collect such an object (e.g.,
|
|
|
|
it has a __del__ method), its gc_refs is restored to GC_REACHABLE again.
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
*/
|
2002-07-01 21:52:30 -03:00
|
|
|
#define GC_UNTRACKED _PyGC_REFS_UNTRACKED
|
|
|
|
#define GC_REACHABLE _PyGC_REFS_REACHABLE
|
|
|
|
#define GC_TENTATIVELY_UNREACHABLE _PyGC_REFS_TENTATIVELY_UNREACHABLE
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
|
2002-07-02 15:12:35 -03:00
|
|
|
#define IS_TRACKED(o) ((AS_GC(o))->gc.gc_refs != GC_UNTRACKED)
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
#define IS_REACHABLE(o) ((AS_GC(o))->gc.gc_refs == GC_REACHABLE)
|
|
|
|
#define IS_TENTATIVELY_UNREACHABLE(o) ( \
|
|
|
|
(AS_GC(o))->gc.gc_refs == GC_TENTATIVELY_UNREACHABLE)
|
2002-05-21 12:53:24 -03:00
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
/*** list functions ***/
|
|
|
|
|
|
|
|
static void
|
|
|
|
gc_list_init(PyGC_Head *list)
|
|
|
|
{
|
2001-10-11 15:31:31 -03:00
|
|
|
list->gc.gc_prev = list;
|
|
|
|
list->gc.gc_next = list;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
static int
|
|
|
|
gc_list_is_empty(PyGC_Head *list)
|
|
|
|
{
|
|
|
|
return (list->gc.gc_next == list);
|
|
|
|
}
|
|
|
|
|
2004-10-31 21:39:08 -04:00
|
|
|
#if 0
|
|
|
|
/* This became unused after gc_list_move() was introduced. */
|
|
|
|
/* Append `node` to `list`. */
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
|
|
|
gc_list_append(PyGC_Head *node, PyGC_Head *list)
|
|
|
|
{
|
2001-10-11 15:31:31 -03: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 02:02:53 -03:00
|
|
|
}
|
2004-10-31 21:39:08 -04:00
|
|
|
#endif
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2004-10-31 21:39:08 -04:00
|
|
|
/* Remove `node` from the gc list it's currently in. */
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
|
|
|
gc_list_remove(PyGC_Head *node)
|
|
|
|
{
|
2001-10-11 15:31:31 -03: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 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2004-10-31 21:39:08 -04:00
|
|
|
/* Move `node` from the gc list it's currently in (which is not explicitly
|
|
|
|
* named here) to the end of `list`. This is semantically the same as
|
|
|
|
* gc_list_remove(node) followed by gc_list_append(node, list).
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
gc_list_move(PyGC_Head *node, PyGC_Head *list)
|
|
|
|
{
|
2004-11-01 12:39:57 -04:00
|
|
|
PyGC_Head *new_prev;
|
2004-10-31 21:39:08 -04:00
|
|
|
PyGC_Head *current_prev = node->gc.gc_prev;
|
|
|
|
PyGC_Head *current_next = node->gc.gc_next;
|
2004-11-01 12:39:57 -04:00
|
|
|
/* Unlink from current list. */
|
2004-10-31 21:39:08 -04:00
|
|
|
current_prev->gc.gc_next = current_next;
|
|
|
|
current_next->gc.gc_prev = current_prev;
|
2004-11-01 12:39:57 -04:00
|
|
|
/* Relink at end of new list. */
|
|
|
|
new_prev = node->gc.gc_prev = list->gc.gc_prev;
|
2004-10-31 21:39:08 -04:00
|
|
|
new_prev->gc.gc_next = list->gc.gc_prev = node;
|
2004-11-01 12:39:57 -04:00
|
|
|
node->gc.gc_next = list;
|
2004-10-31 21:39:08 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* append list `from` onto list `to`; `from` becomes an empty list */
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
|
|
|
gc_list_merge(PyGC_Head *from, PyGC_Head *to)
|
|
|
|
{
|
|
|
|
PyGC_Head *tail;
|
2004-10-31 21:39:08 -04:00
|
|
|
assert(from != to);
|
2002-05-04 02:35:20 -03:00
|
|
|
if (!gc_list_is_empty(from)) {
|
2001-10-11 15:31:31 -03:00
|
|
|
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 02:02:53 -03:00
|
|
|
}
|
|
|
|
gc_list_init(from);
|
|
|
|
}
|
|
|
|
|
2006-03-04 16:01:53 -04:00
|
|
|
static Py_ssize_t
|
2000-06-30 02:02:53 -03:00
|
|
|
gc_list_size(PyGC_Head *list)
|
|
|
|
{
|
|
|
|
PyGC_Head *gc;
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t n = 0;
|
2001-10-11 15:31:31 -03:00
|
|
|
for (gc = list->gc.gc_next; gc != list; gc = gc->gc.gc_next) {
|
2000-06-30 02:02:53 -03:00
|
|
|
n++;
|
|
|
|
}
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
2003-04-06 16:41:39 -03:00
|
|
|
/* Append objects in a GC list to a Python list.
|
|
|
|
* Return 0 if all OK, < 0 if error (out of memory for list).
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
append_objects(PyObject *py_list, PyGC_Head *gc_list)
|
|
|
|
{
|
|
|
|
PyGC_Head *gc;
|
|
|
|
for (gc = gc_list->gc.gc_next; gc != gc_list; gc = gc->gc.gc_next) {
|
|
|
|
PyObject *op = FROM_GC(gc);
|
|
|
|
if (op != py_list) {
|
|
|
|
if (PyList_Append(py_list, op)) {
|
|
|
|
return -1; /* exception */
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
/*** end of list stuff ***/
|
|
|
|
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Set all gc_refs = ob_refcnt. After this, gc_refs is > 0 for all objects
|
|
|
|
* in containers, and is GC_REACHABLE for all tracked gc objects not in
|
|
|
|
* containers.
|
SF bug #574132: Major GC related performance regression
"The regression" is actually due to that 2.2.1 had a bug that prevented
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.
Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand. 2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).
2002-06-30 14:56:40 -03:00
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
|
|
|
update_refs(PyGC_Head *containers)
|
|
|
|
{
|
2001-10-11 15:31:31 -03:00
|
|
|
PyGC_Head *gc = containers->gc.gc_next;
|
2002-07-01 21:52:30 -03:00
|
|
|
for (; gc != containers; gc = gc->gc.gc_next) {
|
|
|
|
assert(gc->gc.gc_refs == GC_REACHABLE);
|
2001-10-11 15:31:31 -03:00
|
|
|
gc->gc.gc_refs = FROM_GC(gc)->ob_refcnt;
|
2003-11-13 20:01:17 -04:00
|
|
|
/* Python's cyclic gc should never see an incoming refcount
|
|
|
|
* of 0: if something decref'ed to 0, it should have been
|
|
|
|
* deallocated immediately at that time.
|
|
|
|
* Possible cause (if the assert triggers): a tp_dealloc
|
|
|
|
* routine left a gc-aware object tracked during its teardown
|
|
|
|
* phase, and did something-- or allowed something to happen --
|
|
|
|
* that called back into Python. gc can trigger then, and may
|
|
|
|
* see the still-tracked dying object. Before this assert
|
|
|
|
* was added, such mistakes went on to allow gc to try to
|
|
|
|
* delete the object again. In a debug build, that caused
|
|
|
|
* a mysterious segfault, when _Py_ForgetReference tried
|
|
|
|
* to remove the object from the doubly-linked list of all
|
|
|
|
* objects a second time. In a release build, an actual
|
|
|
|
* double deallocation occurred, which leads to corruption
|
|
|
|
* of the allocator's internal bookkeeping pointers. That's
|
|
|
|
* so serious that maybe this should be a release-build
|
|
|
|
* check instead of an assert?
|
|
|
|
*/
|
|
|
|
assert(gc->gc.gc_refs != 0);
|
2002-07-01 21:52:30 -03:00
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* A traversal callback for subtract_refs. */
|
2000-06-30 02:02:53 -03:00
|
|
|
static int
|
|
|
|
visit_decref(PyObject *op, void *data)
|
|
|
|
{
|
2002-06-30 18:31:03 -03:00
|
|
|
assert(op != NULL);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
if (PyObject_IS_GC(op)) {
|
|
|
|
PyGC_Head *gc = AS_GC(op);
|
|
|
|
/* We're only interested in gc_refs for objects in the
|
|
|
|
* generation being collected, which can be recognized
|
|
|
|
* because only they have positive gc_refs.
|
|
|
|
*/
|
2002-07-02 19:15:28 -03:00
|
|
|
assert(gc->gc.gc_refs != 0); /* else refcount was too small */
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
if (gc->gc.gc_refs > 0)
|
|
|
|
gc->gc.gc_refs--;
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Subtract internal references from gc_refs. After this, gc_refs is >= 0
|
|
|
|
* for all objects in containers, and is GC_REACHABLE for all tracked gc
|
|
|
|
* objects not in containers. The ones with gc_refs > 0 are directly
|
|
|
|
* reachable from outside containers, and so can't be collected.
|
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
|
|
|
subtract_refs(PyGC_Head *containers)
|
|
|
|
{
|
|
|
|
traverseproc traverse;
|
2001-10-11 15:31:31 -03:00
|
|
|
PyGC_Head *gc = containers->gc.gc_next;
|
|
|
|
for (; gc != containers; gc=gc->gc.gc_next) {
|
2001-08-29 21:05:51 -03:00
|
|
|
traverse = FROM_GC(gc)->ob_type->tp_traverse;
|
|
|
|
(void) traverse(FROM_GC(gc),
|
2000-06-30 02:02:53 -03:00
|
|
|
(visitproc)visit_decref,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* A traversal callback for move_unreachable. */
|
2000-06-30 02:02:53 -03:00
|
|
|
static int
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
visit_reachable(PyObject *op, PyGC_Head *reachable)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2002-07-01 21:52:30 -03:00
|
|
|
if (PyObject_IS_GC(op)) {
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
PyGC_Head *gc = AS_GC(op);
|
2006-03-01 12:56:25 -04:00
|
|
|
const Py_ssize_t gc_refs = gc->gc.gc_refs;
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
|
|
|
|
if (gc_refs == 0) {
|
|
|
|
/* This is in move_unreachable's 'young' list, but
|
|
|
|
* the traversal hasn't yet gotten to it. All
|
|
|
|
* we need to do is tell move_unreachable that it's
|
|
|
|
* reachable.
|
|
|
|
*/
|
|
|
|
gc->gc.gc_refs = 1;
|
|
|
|
}
|
|
|
|
else if (gc_refs == GC_TENTATIVELY_UNREACHABLE) {
|
|
|
|
/* This had gc_refs = 0 when move_unreachable got
|
|
|
|
* to it, but turns out it's reachable after all.
|
|
|
|
* Move it back to move_unreachable's 'young' list,
|
|
|
|
* and move_unreachable will eventually get to it
|
|
|
|
* again.
|
|
|
|
*/
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, reachable);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
gc->gc.gc_refs = 1;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Else there's nothing to do.
|
|
|
|
* If gc_refs > 0, it must be in move_unreachable's 'young'
|
|
|
|
* list, and move_unreachable will eventually get to it.
|
|
|
|
* If gc_refs == GC_REACHABLE, it's either in some other
|
|
|
|
* generation so we don't care about it, or move_unreachable
|
2002-07-02 15:12:35 -03:00
|
|
|
* already dealt with it.
|
2002-07-01 21:52:30 -03:00
|
|
|
* If gc_refs == GC_UNTRACKED, it must be ignored.
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
*/
|
2002-07-01 21:52:30 -03:00
|
|
|
else {
|
|
|
|
assert(gc_refs > 0
|
|
|
|
|| gc_refs == GC_REACHABLE
|
|
|
|
|| gc_refs == GC_UNTRACKED);
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Move the unreachable objects from young to unreachable. After this,
|
|
|
|
* all objects in young have gc_refs = GC_REACHABLE, and all objects in
|
|
|
|
* unreachable have gc_refs = GC_TENTATIVELY_UNREACHABLE. All tracked
|
|
|
|
* gc objects not in young or unreachable still have gc_refs = GC_REACHABLE.
|
|
|
|
* All objects in young after this are directly or indirectly reachable
|
|
|
|
* from outside the original young; and all objects in unreachable are
|
|
|
|
* not.
|
SF bug #574132: Major GC related performance regression
"The regression" is actually due to that 2.2.1 had a bug that prevented
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.
Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand. 2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).
2002-06-30 14:56:40 -03:00
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
move_unreachable(PyGC_Head *young, PyGC_Head *unreachable)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
PyGC_Head *gc = young->gc.gc_next;
|
|
|
|
|
|
|
|
/* Invariants: all objects "to the left" of us in young have gc_refs
|
|
|
|
* = GC_REACHABLE, and are indeed reachable (directly or indirectly)
|
|
|
|
* from outside the young list as it was at entry. All other objects
|
|
|
|
* from the original young "to the left" of us are in unreachable now,
|
|
|
|
* and have gc_refs = GC_TENTATIVELY_UNREACHABLE. All objects to the
|
|
|
|
* left of us in 'young' now have been scanned, and no objects here
|
|
|
|
* or to the right have been scanned yet.
|
|
|
|
*/
|
|
|
|
|
|
|
|
while (gc != young) {
|
|
|
|
PyGC_Head *next;
|
|
|
|
|
2002-07-02 15:12:35 -03:00
|
|
|
if (gc->gc.gc_refs) {
|
|
|
|
/* gc is definitely reachable from outside the
|
|
|
|
* original 'young'. Mark it as such, and traverse
|
|
|
|
* its pointers to find any other objects that may
|
|
|
|
* be directly reachable from it. Note that the
|
|
|
|
* call to tp_traverse may append objects to young,
|
|
|
|
* so we have to wait until it returns to determine
|
|
|
|
* the next object to visit.
|
|
|
|
*/
|
|
|
|
PyObject *op = FROM_GC(gc);
|
|
|
|
traverseproc traverse = op->ob_type->tp_traverse;
|
|
|
|
assert(gc->gc.gc_refs > 0);
|
|
|
|
gc->gc.gc_refs = GC_REACHABLE;
|
|
|
|
(void) traverse(op,
|
|
|
|
(visitproc)visit_reachable,
|
|
|
|
(void *)young);
|
|
|
|
next = gc->gc.gc_next;
|
|
|
|
}
|
|
|
|
else {
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* This *may* be unreachable. To make progress,
|
|
|
|
* assume it is. gc isn't directly reachable from
|
|
|
|
* any object we've already traversed, but may be
|
|
|
|
* reachable from an object we haven't gotten to yet.
|
|
|
|
* visit_reachable will eventually move gc back into
|
|
|
|
* young if that's so, and we'll see it again.
|
|
|
|
*/
|
|
|
|
next = gc->gc.gc_next;
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, unreachable);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
gc->gc.gc_refs = GC_TENTATIVELY_UNREACHABLE;
|
|
|
|
}
|
|
|
|
gc = next;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-04-05 13:35:54 -04:00
|
|
|
/* Return true if object has a finalization method.
|
|
|
|
* CAUTION: An instance of an old-style class has to be checked for a
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
*__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.
|
2003-04-05 13:35:54 -04:00
|
|
|
*/
|
2001-11-01 13:35:23 -04:00
|
|
|
static int
|
|
|
|
has_finalizer(PyObject *op)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2003-04-05 13:35:54 -04:00
|
|
|
if (PyInstance_Check(op)) {
|
|
|
|
assert(delstr != NULL);
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
return _PyInstance_Lookup(op, delstr) != NULL;
|
2003-04-05 13:35:54 -04:00
|
|
|
}
|
2006-04-10 14:51:05 -03:00
|
|
|
else if (PyType_HasFeature(op->ob_type, Py_TPFLAGS_HEAPTYPE))
|
2003-04-05 13:35:54 -04:00
|
|
|
return op->ob_type->tp_del != NULL;
|
2006-04-10 14:51:05 -03:00
|
|
|
else if (PyGen_CheckExact(op))
|
|
|
|
return PyGen_NeedsFinalizing((PyGenObject *)op);
|
|
|
|
else
|
|
|
|
return 0;
|
2001-11-01 13:35:23 -04:00
|
|
|
}
|
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
/* Move the objects in unreachable with __del__ methods into `finalizers`.
|
|
|
|
* Objects moved into `finalizers` have gc_refs set to GC_REACHABLE; the
|
|
|
|
* objects remaining in unreachable are left at GC_TENTATIVELY_UNREACHABLE.
|
2003-04-04 15:59:06 -04:00
|
|
|
*/
|
2001-11-01 13:35:23 -04:00
|
|
|
static void
|
2004-10-30 20:09:22 -03:00
|
|
|
move_finalizers(PyGC_Head *unreachable, PyGC_Head *finalizers)
|
2001-11-01 13:35:23 -04:00
|
|
|
{
|
2004-10-30 20:09:22 -03:00
|
|
|
PyGC_Head *gc;
|
|
|
|
PyGC_Head *next;
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
/* March over unreachable. Move objects with finalizers into
|
|
|
|
* `finalizers`.
|
|
|
|
*/
|
|
|
|
for (gc = unreachable->gc.gc_next; gc != unreachable; gc = next) {
|
2001-08-29 21:05:51 -03:00
|
|
|
PyObject *op = FROM_GC(gc);
|
2003-04-04 15:59:06 -04:00
|
|
|
|
2003-04-05 14:40:50 -04:00
|
|
|
assert(IS_TENTATIVELY_UNREACHABLE(op));
|
2004-10-30 20:09:22 -03:00
|
|
|
next = gc->gc.gc_next;
|
2003-04-05 14:40:50 -04:00
|
|
|
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
if (has_finalizer(op)) {
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, finalizers);
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
gc->gc.gc_refs = GC_REACHABLE;
|
2003-04-04 15:59:06 -04:00
|
|
|
}
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* A traversal callback for move_finalizer_reachable. */
|
|
|
|
static int
|
|
|
|
visit_move(PyObject *op, PyGC_Head *tolist)
|
|
|
|
{
|
|
|
|
if (PyObject_IS_GC(op)) {
|
2002-07-01 21:52:30 -03:00
|
|
|
if (IS_TENTATIVELY_UNREACHABLE(op)) {
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
PyGC_Head *gc = AS_GC(op);
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, tolist);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
gc->gc.gc_refs = GC_REACHABLE;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
return 0;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Move objects that are reachable from finalizers, from the unreachable set
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
* into finalizers set.
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
move_finalizer_reachable(PyGC_Head *finalizers)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
|
|
|
traverseproc traverse;
|
2001-10-11 15:31:31 -03:00
|
|
|
PyGC_Head *gc = finalizers->gc.gc_next;
|
2003-04-05 20:11:39 -04:00
|
|
|
for (; gc != finalizers; gc = gc->gc.gc_next) {
|
|
|
|
/* Note that the finalizers list may grow during this. */
|
2001-08-29 21:05:51 -03:00
|
|
|
traverse = FROM_GC(gc)->ob_type->tp_traverse;
|
SF bug #574132: Major GC related performance regression
"The regression" is actually due to that 2.2.1 had a bug that prevented
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.
Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand. 2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).
2002-06-30 14:56:40 -03:00
|
|
|
(void) traverse(FROM_GC(gc),
|
2003-04-05 20:11:39 -04:00
|
|
|
(visitproc)visit_move,
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
(void *)finalizers);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
/* Clear all weakrefs to unreachable objects, and if such a weakref has a
|
|
|
|
* callback, invoke it if necessary. Note that it's possible for such
|
|
|
|
* weakrefs to be outside the unreachable set -- indeed, those are precisely
|
|
|
|
* the weakrefs whose callbacks must be invoked. See gc_weakref.txt for
|
|
|
|
* overview & some details. Some weakrefs with callbacks may be reclaimed
|
|
|
|
* directly by this routine; the number reclaimed is the return value. Other
|
|
|
|
* weakrefs with callbacks may be moved into the `old` generation. Objects
|
|
|
|
* moved into `old` have gc_refs set to GC_REACHABLE; the objects remaining in
|
|
|
|
* unreachable are left at GC_TENTATIVELY_UNREACHABLE. When this returns,
|
|
|
|
* no object in `unreachable` is weakly referenced anymore.
|
2003-11-20 17:21:46 -04:00
|
|
|
*/
|
2004-10-30 20:09:22 -03:00
|
|
|
static int
|
|
|
|
handle_weakrefs(PyGC_Head *unreachable, PyGC_Head *old)
|
2003-11-20 17:21:46 -04:00
|
|
|
{
|
2004-10-30 20:09:22 -03:00
|
|
|
PyGC_Head *gc;
|
|
|
|
PyObject *op; /* generally FROM_GC(gc) */
|
|
|
|
PyWeakReference *wr; /* generally a cast of op */
|
|
|
|
PyGC_Head wrcb_to_call; /* weakrefs with callbacks to call */
|
|
|
|
PyGC_Head *next;
|
|
|
|
int num_freed = 0;
|
|
|
|
|
|
|
|
gc_list_init(&wrcb_to_call);
|
|
|
|
|
|
|
|
/* Clear all weakrefs to the objects in unreachable. If such a weakref
|
|
|
|
* also has a callback, move it into `wrcb_to_call` if the callback
|
2004-10-31 18:12:43 -04:00
|
|
|
* needs to be invoked. Note that we cannot invoke any callbacks until
|
|
|
|
* all weakrefs to unreachable objects are cleared, lest the callback
|
|
|
|
* resurrect an unreachable object via a still-active weakref. We
|
|
|
|
* make another pass over wrcb_to_call, invoking callbacks, after this
|
|
|
|
* pass completes.
|
2004-10-30 20:09:22 -03:00
|
|
|
*/
|
|
|
|
for (gc = unreachable->gc.gc_next; gc != unreachable; gc = next) {
|
|
|
|
PyWeakReference **wrlist;
|
|
|
|
|
|
|
|
op = FROM_GC(gc);
|
|
|
|
assert(IS_TENTATIVELY_UNREACHABLE(op));
|
|
|
|
next = gc->gc.gc_next;
|
2003-11-20 17:21:46 -04:00
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
if (! PyType_SUPPORTS_WEAKREFS(op->ob_type))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* It supports weakrefs. Does it have any? */
|
|
|
|
wrlist = (PyWeakReference **)
|
|
|
|
PyObject_GET_WEAKREFS_LISTPTR(op);
|
|
|
|
|
|
|
|
/* `op` may have some weakrefs. March over the list, clear
|
|
|
|
* all the weakrefs, and move the weakrefs with callbacks
|
2004-10-31 18:12:43 -04:00
|
|
|
* that must be called into wrcb_to_call.
|
2004-10-30 20:09:22 -03:00
|
|
|
*/
|
|
|
|
for (wr = *wrlist; wr != NULL; wr = *wrlist) {
|
|
|
|
PyGC_Head *wrasgc; /* AS_GC(wr) */
|
|
|
|
|
|
|
|
/* _PyWeakref_ClearRef clears the weakref but leaves
|
|
|
|
* the callback pointer intact. Obscure: it also
|
|
|
|
* changes *wrlist.
|
|
|
|
*/
|
|
|
|
assert(wr->wr_object == op);
|
|
|
|
_PyWeakref_ClearRef(wr);
|
|
|
|
assert(wr->wr_object == Py_None);
|
|
|
|
if (wr->wr_callback == NULL)
|
|
|
|
continue; /* no callback */
|
|
|
|
|
|
|
|
/* Headache time. `op` is going away, and is weakly referenced by
|
|
|
|
* `wr`, which has a callback. Should the callback be invoked? If wr
|
|
|
|
* is also trash, no:
|
|
|
|
*
|
|
|
|
* 1. There's no need to call it. The object and the weakref are
|
|
|
|
* both going away, so it's legitimate to pretend the weakref is
|
|
|
|
* going away first. The user has to ensure a weakref outlives its
|
|
|
|
* referent if they want a guarantee that the wr callback will get
|
|
|
|
* invoked.
|
|
|
|
*
|
|
|
|
* 2. It may be catastrophic to call it. If the callback is also in
|
|
|
|
* cyclic trash (CT), then although the CT is unreachable from
|
|
|
|
* outside the current generation, CT may be reachable from the
|
|
|
|
* callback. Then the callback could resurrect insane objects.
|
|
|
|
*
|
|
|
|
* Since the callback is never needed and may be unsafe in this case,
|
2004-10-31 18:12:43 -04:00
|
|
|
* wr is simply left in the unreachable set. Note that because we
|
|
|
|
* already called _PyWeakref_ClearRef(wr), its callback will never
|
|
|
|
* trigger.
|
2004-10-30 20:09:22 -03:00
|
|
|
*
|
|
|
|
* OTOH, if wr isn't part of CT, we should invoke the callback: the
|
|
|
|
* weakref outlived the trash. Note that since wr isn't CT in this
|
|
|
|
* case, its callback can't be CT either -- wr acted as an external
|
|
|
|
* root to this generation, and therefore its callback did too. So
|
|
|
|
* nothing in CT is reachable from the callback either, so it's hard
|
|
|
|
* to imagine how calling it later could create a problem for us. wr
|
|
|
|
* is moved to wrcb_to_call in this case.
|
|
|
|
*/
|
2004-10-31 18:12:43 -04:00
|
|
|
if (IS_TENTATIVELY_UNREACHABLE(wr))
|
|
|
|
continue;
|
|
|
|
assert(IS_REACHABLE(wr));
|
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
/* Create a new reference so that wr can't go away
|
|
|
|
* before we can process it again.
|
|
|
|
*/
|
|
|
|
Py_INCREF(wr);
|
|
|
|
|
2004-10-31 18:12:43 -04:00
|
|
|
/* Move wr to wrcb_to_call, for the next pass. */
|
2004-10-30 20:09:22 -03:00
|
|
|
wrasgc = AS_GC(wr);
|
2004-10-31 18:12:43 -04:00
|
|
|
assert(wrasgc != next); /* wrasgc is reachable, but
|
|
|
|
next isn't, so they can't
|
|
|
|
be the same */
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(wrasgc, &wrcb_to_call);
|
2004-10-30 20:09:22 -03:00
|
|
|
}
|
|
|
|
}
|
2003-11-20 17:21:46 -04:00
|
|
|
|
2004-10-31 18:12:43 -04:00
|
|
|
/* Invoke the callbacks we decided to honor. It's safe to invoke them
|
|
|
|
* because they can't reference unreachable objects.
|
2004-10-30 20:09:22 -03:00
|
|
|
*/
|
|
|
|
while (! gc_list_is_empty(&wrcb_to_call)) {
|
|
|
|
PyObject *temp;
|
|
|
|
PyObject *callback;
|
2003-11-20 17:21:46 -04:00
|
|
|
|
2004-10-30 20:09:22 -03:00
|
|
|
gc = wrcb_to_call.gc.gc_next;
|
|
|
|
op = FROM_GC(gc);
|
2003-11-20 17:21:46 -04:00
|
|
|
assert(IS_REACHABLE(op));
|
|
|
|
assert(PyWeakref_Check(op));
|
2004-10-30 20:09:22 -03:00
|
|
|
wr = (PyWeakReference *)op;
|
|
|
|
callback = wr->wr_callback;
|
|
|
|
assert(callback != NULL);
|
|
|
|
|
|
|
|
/* copy-paste of weakrefobject.c's handle_callback() */
|
|
|
|
temp = PyObject_CallFunction(callback, "O", wr);
|
|
|
|
if (temp == NULL)
|
|
|
|
PyErr_WriteUnraisable(callback);
|
|
|
|
else
|
|
|
|
Py_DECREF(temp);
|
|
|
|
|
|
|
|
/* Give up the reference we created in the first pass. When
|
|
|
|
* op's refcount hits 0 (which it may or may not do right now),
|
2004-10-31 18:12:43 -04:00
|
|
|
* op's tp_dealloc will decref op->wr_callback too. Note
|
|
|
|
* that the refcount probably will hit 0 now, and because this
|
|
|
|
* weakref was reachable to begin with, gc didn't already
|
|
|
|
* add it to its count of freed objects. Example: a reachable
|
|
|
|
* weak value dict maps some key to this reachable weakref.
|
|
|
|
* The callback removes this key->weakref mapping from the
|
|
|
|
* dict, leaving no other references to the weakref (excepting
|
|
|
|
* ours).
|
2004-10-30 20:09:22 -03:00
|
|
|
*/
|
2003-11-20 17:21:46 -04:00
|
|
|
Py_DECREF(op);
|
2004-10-30 20:09:22 -03:00
|
|
|
if (wrcb_to_call.gc.gc_next == gc) {
|
2003-11-20 17:21:46 -04:00
|
|
|
/* object is still alive -- move it */
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, old);
|
2003-11-20 17:21:46 -04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
++num_freed;
|
|
|
|
}
|
2004-10-30 20:09:22 -03:00
|
|
|
|
2003-11-20 17:21:46 -04:00
|
|
|
return num_freed;
|
|
|
|
}
|
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
2000-08-31 12:10:24 -03:00
|
|
|
debug_instance(char *msg, PyInstanceObject *inst)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
|
|
|
char *cname;
|
2001-11-01 13:35:23 -04:00
|
|
|
/* simple version of instance_repr */
|
2000-06-30 02:02:53 -03:00
|
|
|
PyObject *classname = inst->in_class->cl_name;
|
|
|
|
if (classname != NULL && PyString_Check(classname))
|
|
|
|
cname = PyString_AsString(classname);
|
|
|
|
else
|
|
|
|
cname = "?";
|
2000-08-31 12:10:24 -03:00
|
|
|
PySys_WriteStderr("gc: %.100s <%.100s instance at %p>\n",
|
|
|
|
msg, cname, inst);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2000-08-31 12:10:24 -03:00
|
|
|
debug_cycle(char *msg, PyObject *op)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
|
|
|
if ((debug & DEBUG_INSTANCES) && PyInstance_Check(op)) {
|
2000-08-31 12:10:24 -03:00
|
|
|
debug_instance(msg, (PyInstanceObject *)op);
|
2000-09-22 12:22:38 -03:00
|
|
|
}
|
|
|
|
else if (debug & DEBUG_OBJECTS) {
|
2000-08-31 12:10:24 -03:00
|
|
|
PySys_WriteStderr("gc: %.100s <%.100s %p>\n",
|
|
|
|
msg, op->ob_type->tp_name, op);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-04-05 20:11:39 -04:00
|
|
|
/* Handle uncollectable garbage (cycles with finalizers, and stuff reachable
|
|
|
|
* only from such cycles).
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
* If DEBUG_SAVEALL, all objects in finalizers are appended to the module
|
|
|
|
* garbage list (a Python list), else only the objects in finalizers with
|
|
|
|
* __del__ methods are appended to garbage. All objects in finalizers are
|
|
|
|
* merged into the old list regardless.
|
2003-04-06 16:41:39 -03:00
|
|
|
* Returns 0 if all OK, <0 on error (out of memory to grow the garbage list).
|
|
|
|
* The finalizers list is made empty on a successful return.
|
2003-04-05 20:11:39 -04:00
|
|
|
*/
|
2003-04-06 16:41:39 -03:00
|
|
|
static int
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
handle_finalizers(PyGC_Head *finalizers, PyGC_Head *old)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
PyGC_Head *gc = finalizers->gc.gc_next;
|
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
if (garbage == NULL) {
|
|
|
|
garbage = PyList_New(0);
|
2003-04-05 20:11:39 -04:00
|
|
|
if (garbage == NULL)
|
|
|
|
Py_FatalError("gc couldn't create gc.garbage list");
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
for (; gc != finalizers; gc = gc->gc.gc_next) {
|
|
|
|
PyObject *op = FROM_GC(gc);
|
|
|
|
|
|
|
|
if ((debug & DEBUG_SAVEALL) || has_finalizer(op)) {
|
|
|
|
if (PyList_Append(garbage, op) < 0)
|
|
|
|
return -1;
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
|
2003-04-06 16:41:39 -03:00
|
|
|
gc_list_merge(finalizers, old);
|
|
|
|
return 0;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2000-09-22 12:22:38 -03:00
|
|
|
/* Break reference cycles by clearing the containers involved. This is
|
2000-06-30 02:02:53 -03:00
|
|
|
* tricky business as the lists can be changing and we don't know which
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
* objects may be freed. It is possible I screwed something up here.
|
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
static void
|
2003-04-04 15:59:06 -04:00
|
|
|
delete_garbage(PyGC_Head *collectable, PyGC_Head *old)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
|
|
|
inquiry clear;
|
|
|
|
|
2003-04-04 15:59:06 -04:00
|
|
|
while (!gc_list_is_empty(collectable)) {
|
|
|
|
PyGC_Head *gc = collectable->gc.gc_next;
|
2001-08-29 21:05:51 -03:00
|
|
|
PyObject *op = FROM_GC(gc);
|
SF bug #574132: Major GC related performance regression
"The regression" is actually due to that 2.2.1 had a bug that prevented
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.
Bugfix candidate, although the code has changed enough that I think I'll
need to port it by hand. 2.2.1 also has a different bug that causes
bound method objects not to get tracked at all (so the test case doesn't
burn absurd amounts of time in 2.2.1, but *should* <wink>).
2002-06-30 14:56:40 -03:00
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
assert(IS_TENTATIVELY_UNREACHABLE(op));
|
2000-09-22 12:22:38 -03:00
|
|
|
if (debug & DEBUG_SAVEALL) {
|
|
|
|
PyList_Append(garbage, op);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
if ((clear = op->ob_type->tp_clear) != NULL) {
|
|
|
|
Py_INCREF(op);
|
2002-06-06 20:23:55 -03:00
|
|
|
clear(op);
|
2000-09-22 12:22:38 -03:00
|
|
|
Py_DECREF(op);
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
2003-04-04 15:59:06 -04:00
|
|
|
if (collectable->gc.gc_next == gc) {
|
2000-09-22 12:22:38 -03:00
|
|
|
/* object is still alive, move it, it may die later */
|
2004-10-31 21:39:08 -04:00
|
|
|
gc_list_move(gc, old);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
gc->gc.gc_refs = GC_REACHABLE;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This is the main function. Read this to understand how the
|
|
|
|
* collection process works. */
|
2006-03-04 16:01:53 -04:00
|
|
|
static Py_ssize_t
|
2002-05-04 02:35:20 -03:00
|
|
|
collect(int generation)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
int i;
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t m = 0; /* # objects collected */
|
|
|
|
Py_ssize_t n = 0; /* # unreachable objects that couldn't be collected */
|
2002-05-04 02:35:20 -03:00
|
|
|
PyGC_Head *young; /* the generation we are examining */
|
|
|
|
PyGC_Head *old; /* next older generation */
|
2003-11-20 17:21:46 -04:00
|
|
|
PyGC_Head unreachable; /* non-problematic unreachable trash */
|
|
|
|
PyGC_Head finalizers; /* objects with, & reachable from, __del__ */
|
2000-06-30 02:02:53 -03:00
|
|
|
PyGC_Head *gc;
|
|
|
|
|
2003-04-05 13:15:44 -04:00
|
|
|
if (delstr == NULL) {
|
|
|
|
delstr = PyString_InternFromString("__del__");
|
|
|
|
if (delstr == NULL)
|
|
|
|
Py_FatalError("gc couldn't allocate \"__del__\"");
|
|
|
|
}
|
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
if (debug & DEBUG_STATS) {
|
2002-05-04 02:35:20 -03:00
|
|
|
PySys_WriteStderr("gc: collecting generation %d...\n",
|
|
|
|
generation);
|
|
|
|
PySys_WriteStderr("gc: objects in each generation:");
|
2006-03-28 17:44:32 -04:00
|
|
|
for (i = 0; i < NUM_GENERATIONS; i++)
|
|
|
|
PySys_WriteStderr(" %" PY_FORMAT_SIZE_T "d",
|
|
|
|
gc_list_size(GEN_HEAD(i)));
|
2002-05-04 02:35:20 -03:00
|
|
|
PySys_WriteStderr("\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update collection and allocation counters */
|
|
|
|
if (generation+1 < NUM_GENERATIONS)
|
|
|
|
generations[generation+1].count += 1;
|
|
|
|
for (i = 0; i <= generation; i++)
|
2002-06-28 16:16:04 -03:00
|
|
|
generations[i].count = 0;
|
2002-05-04 02:35:20 -03:00
|
|
|
|
|
|
|
/* merge younger generations with one we are currently collecting */
|
|
|
|
for (i = 0; i < generation; i++) {
|
|
|
|
gc_list_merge(GEN_HEAD(i), GEN_HEAD(generation));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* handy references */
|
|
|
|
young = GEN_HEAD(generation);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
if (generation < NUM_GENERATIONS-1)
|
2002-05-04 02:35:20 -03:00
|
|
|
old = GEN_HEAD(generation+1);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
else
|
|
|
|
old = young;
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
/* Using ob_refcnt and gc_refs, calculate which objects in the
|
2004-10-30 20:09:22 -03:00
|
|
|
* container set are reachable from outside the set (i.e., have a
|
2000-06-30 02:02:53 -03:00
|
|
|
* refcount greater than 0 when all the references within the
|
2004-10-30 20:09:22 -03:00
|
|
|
* set are taken into account).
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
update_refs(young);
|
|
|
|
subtract_refs(young);
|
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Leave everything reachable from outside young in young, and move
|
|
|
|
* everything else (in young) to unreachable.
|
|
|
|
* NOTE: This used to move the reachable objects into a reachable
|
|
|
|
* set instead. But most things usually turn out to be reachable,
|
|
|
|
* so it's more efficient to move the unreachable things.
|
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
gc_list_init(&unreachable);
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
move_unreachable(young, &unreachable);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* Move reachable objects to next generation. */
|
|
|
|
if (young != old)
|
|
|
|
gc_list_merge(young, old);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
OK, I couldn't stand it <0.5 wink>: removed all uncertainty about what's
in gc_refs, even at the cost of putting back a test+branch in
visit_decref.
The good news: since gc_refs became utterly tame then, it became
clear that another special value could be useful. The move_roots() and
move_root_reachable() passes have now been replaced by a single
move_unreachable() pass. Besides saving a pass over the generation, this
has a better effect: most of the time everything turns out to be
reachable, so we were breaking the generation list apart and moving it
into into the reachable list, one element at a time. Now the reachable
stuff stays in the generation list, and the unreachable stuff is moved
instead. This isn't quite as good as it sounds, since sometimes we
guess wrongly that a thing is unreachable, and have to move it back again.
Still, overall, it yields a significant (but not dramatic) boost in
collection speed.
2002-07-01 00:52:19 -03:00
|
|
|
/* All objects in unreachable are trash, but objects reachable from
|
|
|
|
* finalizers can't safely be deleted. Python programmers should take
|
|
|
|
* care not to create such things. For Python, finalizers means
|
2003-11-20 17:21:46 -04:00
|
|
|
* instance objects with __del__ methods. Weakrefs with callbacks
|
2004-10-30 20:09:22 -03:00
|
|
|
* can also call arbitrary Python code but they will be dealt with by
|
|
|
|
* handle_weakrefs().
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
*/
|
2000-06-30 02:02:53 -03:00
|
|
|
gc_list_init(&finalizers);
|
2004-10-30 20:09:22 -03:00
|
|
|
move_finalizers(&unreachable, &finalizers);
|
2003-04-05 20:11:39 -04:00
|
|
|
/* finalizers contains the unreachable objects with a finalizer;
|
2003-11-20 17:21:46 -04:00
|
|
|
* unreachable objects reachable *from* those are also uncollectable,
|
|
|
|
* and we move those into the finalizers list too.
|
2003-04-05 20:11:39 -04:00
|
|
|
*/
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
move_finalizer_reachable(&finalizers);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
/* Collect statistics on collectable objects found and print
|
2003-11-20 17:21:46 -04:00
|
|
|
* debugging information.
|
|
|
|
*/
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
for (gc = unreachable.gc.gc_next; gc != &unreachable;
|
2001-10-11 15:31:31 -03:00
|
|
|
gc = gc->gc.gc_next) {
|
2000-06-30 02:02:53 -03:00
|
|
|
m++;
|
2000-08-31 12:10:24 -03:00
|
|
|
if (debug & DEBUG_COLLECTABLE) {
|
2001-08-29 21:05:51 -03:00
|
|
|
debug_cycle("collectable", FROM_GC(gc));
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
2004-10-30 20:09:22 -03:00
|
|
|
|
|
|
|
/* Clear weakrefs and invoke callbacks as necessary. */
|
|
|
|
m += handle_weakrefs(&unreachable, old);
|
|
|
|
|
2003-04-07 19:41:24 -03:00
|
|
|
/* Call tp_clear on objects in the unreachable set. This will cause
|
|
|
|
* the reference cycles to be broken. It may also cause some objects
|
|
|
|
* in finalizers to be freed.
|
|
|
|
*/
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
delete_garbage(&unreachable, old);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
/* Collect statistics on uncollectable objects found and print
|
|
|
|
* debugging information. */
|
2003-04-05 21:50:50 -04:00
|
|
|
for (gc = finalizers.gc.gc_next;
|
2003-04-05 20:11:39 -04:00
|
|
|
gc != &finalizers;
|
|
|
|
gc = gc->gc.gc_next) {
|
2000-06-30 02:02:53 -03:00
|
|
|
n++;
|
2003-04-05 20:11:39 -04:00
|
|
|
if (debug & DEBUG_UNCOLLECTABLE)
|
|
|
|
debug_cycle("uncollectable", FROM_GC(gc));
|
|
|
|
}
|
2000-08-31 12:10:24 -03:00
|
|
|
if (debug & DEBUG_STATS) {
|
2006-03-28 17:44:32 -04:00
|
|
|
if (m == 0 && n == 0)
|
2000-08-31 12:10:24 -03:00
|
|
|
PySys_WriteStderr("gc: done.\n");
|
2006-03-28 17:44:32 -04:00
|
|
|
else
|
2000-08-31 12:10:24 -03:00
|
|
|
PySys_WriteStderr(
|
2006-03-28 17:44:32 -04:00
|
|
|
"gc: done, "
|
|
|
|
"%" PY_FORMAT_SIZE_T "d unreachable, "
|
|
|
|
"%" PY_FORMAT_SIZE_T "d uncollectable.\n",
|
2000-08-31 12:10:24 -03:00
|
|
|
n+m, n);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Append instances in the uncollectable set to a Python
|
|
|
|
* reachable list of garbage. The programmer has to deal with
|
2003-04-05 20:11:39 -04:00
|
|
|
* this if they insist on creating this type of structure.
|
|
|
|
*/
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
(void)handle_finalizers(&finalizers, old);
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2000-08-31 23:47:25 -03:00
|
|
|
if (PyErr_Occurred()) {
|
Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 16:21:15 -03:00
|
|
|
if (gc_str == NULL)
|
2003-04-07 19:41:24 -03:00
|
|
|
gc_str = PyString_FromString("garbage collection");
|
2000-08-31 23:47:25 -03:00
|
|
|
PyErr_WriteUnraisable(gc_str);
|
|
|
|
Py_FatalError("unexpected exception during garbage collection");
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
return n+m;
|
|
|
|
}
|
|
|
|
|
2006-03-04 16:01:53 -04:00
|
|
|
static Py_ssize_t
|
2000-06-30 02:02:53 -03:00
|
|
|
collect_generations(void)
|
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
int i;
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t n = 0;
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
/* Find the oldest generation (higest numbered) where the count
|
|
|
|
* exceeds the threshold. Objects in the that generation and
|
|
|
|
* generations younger than it will be collected. */
|
|
|
|
for (i = NUM_GENERATIONS-1; i >= 0; i--) {
|
|
|
|
if (generations[i].count > generations[i].threshold) {
|
|
|
|
n = collect(i);
|
|
|
|
break;
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_enable__doc__,
|
2000-08-06 19:45:31 -03:00
|
|
|
"enable() -> None\n"
|
|
|
|
"\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"Enable automatic garbage collection.\n");
|
2000-08-06 19:45:31 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_enable(PyObject *self, PyObject *noargs)
|
2000-08-06 19:45:31 -03:00
|
|
|
{
|
|
|
|
enabled = 1;
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
return Py_None;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_disable__doc__,
|
2000-08-06 19:45:31 -03:00
|
|
|
"disable() -> None\n"
|
|
|
|
"\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"Disable automatic garbage collection.\n");
|
2000-08-06 19:45:31 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_disable(PyObject *self, PyObject *noargs)
|
2000-08-06 19:45:31 -03:00
|
|
|
{
|
|
|
|
enabled = 0;
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
return Py_None;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_isenabled__doc__,
|
2000-08-06 19:45:31 -03:00
|
|
|
"isenabled() -> status\n"
|
|
|
|
"\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"Returns true if automatic garbage collection is enabled.\n");
|
2000-08-06 19:45:31 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_isenabled(PyObject *self, PyObject *noargs)
|
2000-08-06 19:45:31 -03:00
|
|
|
{
|
2004-01-04 00:00:13 -04:00
|
|
|
return PyBool_FromLong((long)enabled);
|
2000-08-06 19:45:31 -03:00
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_collect__doc__,
|
2006-03-07 05:46:03 -04:00
|
|
|
"collect([generation]) -> n\n"
|
2000-06-30 02:02:53 -03:00
|
|
|
"\n"
|
2006-03-07 05:46:03 -04:00
|
|
|
"With no arguments, run a full collection. The optional argument\n"
|
|
|
|
"may be an integer specifying which generation to collect. A ValueError\n"
|
|
|
|
"is raised if the generation number is invalid.\n\n"
|
|
|
|
"The number of unreachable objects is returned.\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2006-03-07 05:46:03 -04:00
|
|
|
gc_collect(PyObject *self, PyObject *args, PyObject *kws)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2006-03-07 05:46:03 -04:00
|
|
|
static char *keywords[] = {"generation", NULL};
|
|
|
|
int genarg = NUM_GENERATIONS - 1;
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t n;
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2006-03-07 05:46:03 -04:00
|
|
|
if (!PyArg_ParseTupleAndKeywords(args, kws, "|i", keywords, &genarg))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
else if (genarg < 0 || genarg >= NUM_GENERATIONS) {
|
|
|
|
PyErr_SetString(PyExc_ValueError, "invalid generation");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2003-04-05 21:50:50 -04:00
|
|
|
if (collecting)
|
2001-10-31 19:09:35 -04:00
|
|
|
n = 0; /* already collecting, don't do anything */
|
|
|
|
else {
|
|
|
|
collecting = 1;
|
2006-03-07 05:46:03 -04:00
|
|
|
n = collect(genarg);
|
2001-10-31 19:09:35 -04:00
|
|
|
collecting = 0;
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2006-03-04 16:01:53 -04:00
|
|
|
return PyInt_FromSsize_t(n);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_set_debug__doc__,
|
2000-06-30 02:02:53 -03: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 12:22:38 -03:00
|
|
|
" DEBUG_SAVEALL - Save objects to gc.garbage rather than freeing them.\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
" DEBUG_LEAK - Debug leaking programs (everything but STATS).\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 19:45:31 -03:00
|
|
|
gc_set_debug(PyObject *self, PyObject *args)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2000-09-22 19:35:36 -03:00
|
|
|
if (!PyArg_ParseTuple(args, "i:set_debug", &debug))
|
2000-06-30 02:02:53 -03:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
return Py_None;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_get_debug__doc__,
|
2000-06-30 02:02:53 -03:00
|
|
|
"get_debug() -> flags\n"
|
|
|
|
"\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"Get the garbage collection debugging flags.\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_get_debug(PyObject *self, PyObject *noargs)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
|
|
|
return Py_BuildValue("i", debug);
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_set_thresh__doc__,
|
2002-01-28 20:53:41 -04:00
|
|
|
"set_threshold(threshold0, [threshold1, threshold2]) -> None\n"
|
2000-06-30 02:02:53 -03:00
|
|
|
"\n"
|
|
|
|
"Sets the collection thresholds. Setting threshold0 to zero disables\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"collection.\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2000-08-06 19:45:31 -03:00
|
|
|
gc_set_thresh(PyObject *self, PyObject *args)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
int i;
|
|
|
|
if (!PyArg_ParseTuple(args, "i|ii:set_threshold",
|
|
|
|
&generations[0].threshold,
|
|
|
|
&generations[1].threshold,
|
|
|
|
&generations[2].threshold))
|
2000-06-30 02:02:53 -03:00
|
|
|
return NULL;
|
2002-05-04 02:35:20 -03:00
|
|
|
for (i = 2; i < NUM_GENERATIONS; i++) {
|
|
|
|
/* generations higher than 2 get the same threshold */
|
|
|
|
generations[i].threshold = generations[2].threshold;
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
Py_INCREF(Py_None);
|
|
|
|
return Py_None;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_get_thresh__doc__,
|
2000-06-30 02:02:53 -03:00
|
|
|
"get_threshold() -> (threshold0, threshold1, threshold2)\n"
|
|
|
|
"\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"Return the current collection thresholds\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_get_thresh(PyObject *self, PyObject *noargs)
|
2000-06-30 02:02:53 -03:00
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
return Py_BuildValue("(iii)",
|
|
|
|
generations[0].threshold,
|
|
|
|
generations[1].threshold,
|
|
|
|
generations[2].threshold);
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2006-03-07 05:46:03 -04:00
|
|
|
PyDoc_STRVAR(gc_get_count__doc__,
|
|
|
|
"get_count() -> (count0, count1, count2)\n"
|
|
|
|
"\n"
|
|
|
|
"Return the current collection counts\n");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
gc_get_count(PyObject *self, PyObject *noargs)
|
|
|
|
{
|
|
|
|
return Py_BuildValue("(iii)",
|
|
|
|
generations[0].count,
|
|
|
|
generations[1].count,
|
|
|
|
generations[2].count);
|
|
|
|
}
|
|
|
|
|
2001-08-09 12:38:31 -03:00
|
|
|
static int
|
2001-11-24 05:24:51 -04:00
|
|
|
referrersvisit(PyObject* obj, PyObject *objs)
|
2001-08-09 12:38:31 -03:00
|
|
|
{
|
2006-04-06 05:07:25 -03:00
|
|
|
Py_ssize_t i;
|
2001-11-29 14:08:31 -04:00
|
|
|
for (i = 0; i < PyTuple_GET_SIZE(objs); i++)
|
|
|
|
if (PyTuple_GET_ITEM(objs, i) == obj)
|
|
|
|
return 1;
|
2001-08-09 12:38:31 -03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-08-10 11:46:47 -03:00
|
|
|
static int
|
2001-11-24 05:24:51 -04:00
|
|
|
gc_referrers_for(PyObject *objs, PyGC_Head *list, PyObject *resultlist)
|
2001-08-09 12:38:31 -03:00
|
|
|
{
|
|
|
|
PyGC_Head *gc;
|
|
|
|
PyObject *obj;
|
|
|
|
traverseproc traverse;
|
2001-10-11 15:31:31 -03:00
|
|
|
for (gc = list->gc.gc_next; gc != list; gc = gc->gc.gc_next) {
|
2001-08-29 21:05:51 -03:00
|
|
|
obj = FROM_GC(gc);
|
2001-08-09 12:38:31 -03:00
|
|
|
traverse = obj->ob_type->tp_traverse;
|
|
|
|
if (obj == objs || obj == resultlist)
|
|
|
|
continue;
|
2001-11-24 05:24:51 -04:00
|
|
|
if (traverse(obj, (visitproc)referrersvisit, objs)) {
|
2001-08-10 11:46:47 -03:00
|
|
|
if (PyList_Append(resultlist, obj) < 0)
|
|
|
|
return 0; /* error */
|
2001-08-09 12:38:31 -03:00
|
|
|
}
|
|
|
|
}
|
2001-08-10 11:46:47 -03:00
|
|
|
return 1; /* no error */
|
2001-08-09 12:38:31 -03:00
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_get_referrers__doc__,
|
2001-11-24 05:24:51 -04:00
|
|
|
"get_referrers(*objs) -> list\n\
|
2002-06-13 17:33:02 -03:00
|
|
|
Return the list of objects that directly refer to any of objs.");
|
2001-08-09 12:38:31 -03:00
|
|
|
|
2001-08-10 11:46:47 -03:00
|
|
|
static PyObject *
|
2001-11-24 05:24:51 -04:00
|
|
|
gc_get_referrers(PyObject *self, PyObject *args)
|
2001-08-09 12:38:31 -03:00
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
int i;
|
2001-08-09 12:38:31 -03:00
|
|
|
PyObject *result = PyList_New(0);
|
2006-03-17 15:03:25 -04:00
|
|
|
if (!result) return NULL;
|
|
|
|
|
2002-05-04 02:35:20 -03:00
|
|
|
for (i = 0; i < NUM_GENERATIONS; i++) {
|
|
|
|
if (!(gc_referrers_for(args, GEN_HEAD(i), result))) {
|
|
|
|
Py_DECREF(result);
|
|
|
|
return NULL;
|
|
|
|
}
|
2001-08-10 11:46:47 -03:00
|
|
|
}
|
2001-08-09 12:38:31 -03:00
|
|
|
return result;
|
|
|
|
}
|
2000-06-30 02:02:53 -03:00
|
|
|
|
2003-04-08 13:39:48 -03:00
|
|
|
/* Append obj to list; return true if error (out of memory), false if OK. */
|
2003-04-03 12:28:38 -04:00
|
|
|
static int
|
2003-04-08 14:17:17 -03:00
|
|
|
referentsvisit(PyObject *obj, PyObject *list)
|
2003-04-03 12:28:38 -04:00
|
|
|
{
|
2003-04-08 13:39:48 -03:00
|
|
|
return PyList_Append(list, obj) < 0;
|
2003-04-03 12:28:38 -04:00
|
|
|
}
|
|
|
|
|
2003-04-08 14:17:17 -03:00
|
|
|
PyDoc_STRVAR(gc_get_referents__doc__,
|
|
|
|
"get_referents(*objs) -> list\n\
|
2003-04-03 12:29:13 -04:00
|
|
|
Return the list of objects that are directly referred to by objs.");
|
2003-04-03 12:28:38 -04:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-08 14:17:17 -03:00
|
|
|
gc_get_referents(PyObject *self, PyObject *args)
|
2003-04-03 12:28:38 -04:00
|
|
|
{
|
2006-04-06 05:07:25 -03:00
|
|
|
Py_ssize_t i;
|
2003-04-03 12:28:38 -04:00
|
|
|
PyObject *result = PyList_New(0);
|
2003-04-08 13:39:48 -03:00
|
|
|
|
|
|
|
if (result == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2003-04-03 12:28:38 -04:00
|
|
|
for (i = 0; i < PyTuple_GET_SIZE(args); i++) {
|
2003-04-08 13:39:48 -03:00
|
|
|
traverseproc traverse;
|
2003-04-05 13:15:44 -04:00
|
|
|
PyObject *obj = PyTuple_GET_ITEM(args, i);
|
2003-04-08 13:39:48 -03:00
|
|
|
|
|
|
|
if (! PyObject_IS_GC(obj))
|
|
|
|
continue;
|
|
|
|
traverse = obj->ob_type->tp_traverse;
|
|
|
|
if (! traverse)
|
2003-04-03 12:28:38 -04:00
|
|
|
continue;
|
2003-04-08 14:17:17 -03:00
|
|
|
if (traverse(obj, (visitproc)referentsvisit, result)) {
|
2003-04-08 13:39:48 -03:00
|
|
|
Py_DECREF(result);
|
2003-04-03 12:28:38 -04:00
|
|
|
return NULL;
|
2003-04-08 13:39:48 -03:00
|
|
|
}
|
2003-04-03 12:28:38 -04:00
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc_get_objects__doc__,
|
2001-08-09 12:58:59 -03:00
|
|
|
"get_objects() -> [...]\n"
|
|
|
|
"\n"
|
|
|
|
"Return a list of objects tracked by the collector (excluding the list\n"
|
2002-06-13 17:33:02 -03:00
|
|
|
"returned).\n");
|
2001-08-09 12:58:59 -03:00
|
|
|
|
|
|
|
static PyObject *
|
2003-04-05 21:50:50 -04:00
|
|
|
gc_get_objects(PyObject *self, PyObject *noargs)
|
2001-08-09 12:58:59 -03:00
|
|
|
{
|
2002-05-04 02:35:20 -03:00
|
|
|
int i;
|
2001-08-09 12:58:59 -03:00
|
|
|
PyObject* result;
|
|
|
|
|
|
|
|
result = PyList_New(0);
|
2003-04-05 21:50:50 -04:00
|
|
|
if (result == NULL)
|
2001-12-02 14:31:02 -04:00
|
|
|
return NULL;
|
2002-05-04 02:35:20 -03:00
|
|
|
for (i = 0; i < NUM_GENERATIONS; i++) {
|
|
|
|
if (append_objects(result, GEN_HEAD(i))) {
|
|
|
|
Py_DECREF(result);
|
|
|
|
return NULL;
|
|
|
|
}
|
2001-12-02 08:21:34 -04:00
|
|
|
}
|
2001-08-09 12:58:59 -03:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-06-13 17:33:02 -03:00
|
|
|
PyDoc_STRVAR(gc__doc__,
|
2000-06-30 02:02:53 -03:00
|
|
|
"This module provides access to the garbage collector for reference cycles.\n"
|
|
|
|
"\n"
|
2000-08-06 19:45:31 -03: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 02:02:53 -03: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 12:58:59 -03:00
|
|
|
"get_objects() -- Return a list of all objects tracked by the collector.\n"
|
2003-04-03 12:28:38 -04:00
|
|
|
"get_referrers() -- Return the list of objects that refer to an object.\n"
|
2003-04-08 14:17:17 -03:00
|
|
|
"get_referents() -- Return the list of objects that an object refers to.\n");
|
2000-06-30 02:02:53 -03:00
|
|
|
|
|
|
|
static PyMethodDef GcMethods[] = {
|
2003-04-05 21:50:50 -04:00
|
|
|
{"enable", gc_enable, METH_NOARGS, gc_enable__doc__},
|
|
|
|
{"disable", gc_disable, METH_NOARGS, gc_disable__doc__},
|
|
|
|
{"isenabled", gc_isenabled, METH_NOARGS, gc_isenabled__doc__},
|
2000-08-06 19:45:31 -03:00
|
|
|
{"set_debug", gc_set_debug, METH_VARARGS, gc_set_debug__doc__},
|
2003-04-05 21:50:50 -04:00
|
|
|
{"get_debug", gc_get_debug, METH_NOARGS, gc_get_debug__doc__},
|
2006-03-07 05:46:03 -04:00
|
|
|
{"get_count", gc_get_count, METH_NOARGS, gc_get_count__doc__},
|
2000-08-06 19:45:31 -03:00
|
|
|
{"set_threshold", gc_set_thresh, METH_VARARGS, gc_set_thresh__doc__},
|
2003-04-05 21:50:50 -04:00
|
|
|
{"get_threshold", gc_get_thresh, METH_NOARGS, gc_get_thresh__doc__},
|
2006-03-07 05:46:03 -04:00
|
|
|
{"collect", (PyCFunction)gc_collect,
|
|
|
|
METH_VARARGS | METH_KEYWORDS, gc_collect__doc__},
|
2003-04-05 21:50:50 -04:00
|
|
|
{"get_objects", gc_get_objects,METH_NOARGS, gc_get_objects__doc__},
|
2001-11-24 05:24:51 -04:00
|
|
|
{"get_referrers", gc_get_referrers, METH_VARARGS,
|
|
|
|
gc_get_referrers__doc__},
|
2003-04-08 14:17:17 -03:00
|
|
|
{"get_referents", gc_get_referents, METH_VARARGS,
|
|
|
|
gc_get_referents__doc__},
|
2000-06-30 02:02:53 -03:00
|
|
|
{NULL, NULL} /* Sentinel */
|
|
|
|
};
|
|
|
|
|
2003-09-04 08:59:50 -03:00
|
|
|
PyMODINIT_FUNC
|
2000-06-30 02:02:53 -03:00
|
|
|
initgc(void)
|
|
|
|
{
|
|
|
|
PyObject *m;
|
|
|
|
|
|
|
|
m = Py_InitModule4("gc",
|
|
|
|
GcMethods,
|
|
|
|
gc__doc__,
|
|
|
|
NULL,
|
|
|
|
PYTHON_API_VERSION);
|
2006-01-19 02:09:39 -04:00
|
|
|
if (m == NULL)
|
|
|
|
return;
|
2003-04-06 20:30:52 -03:00
|
|
|
|
2000-06-30 02:02:53 -03:00
|
|
|
if (garbage == NULL) {
|
|
|
|
garbage = PyList_New(0);
|
2003-04-06 20:30:52 -03:00
|
|
|
if (garbage == NULL)
|
|
|
|
return;
|
|
|
|
}
|
2005-06-18 14:37:06 -03:00
|
|
|
Py_INCREF(garbage);
|
2003-04-06 20:30:52 -03:00
|
|
|
if (PyModule_AddObject(m, "garbage", garbage) < 0)
|
|
|
|
return;
|
|
|
|
#define ADD_INT(NAME) if (PyModule_AddIntConstant(m, #NAME, NAME) < 0) return
|
|
|
|
ADD_INT(DEBUG_STATS);
|
|
|
|
ADD_INT(DEBUG_COLLECTABLE);
|
|
|
|
ADD_INT(DEBUG_UNCOLLECTABLE);
|
|
|
|
ADD_INT(DEBUG_INSTANCES);
|
|
|
|
ADD_INT(DEBUG_OBJECTS);
|
|
|
|
ADD_INT(DEBUG_SAVEALL);
|
|
|
|
ADD_INT(DEBUG_LEAK);
|
|
|
|
#undef ADD_INT
|
2000-06-30 02:02:53 -03:00
|
|
|
}
|
|
|
|
|
2003-04-17 14:29:22 -03:00
|
|
|
/* API to invoke gc.collect() from C */
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t
|
2003-04-17 14:29:22 -03:00
|
|
|
PyGC_Collect(void)
|
|
|
|
{
|
2006-03-04 16:01:53 -04:00
|
|
|
Py_ssize_t n;
|
2003-04-17 14:29:22 -03:00
|
|
|
|
|
|
|
if (collecting)
|
|
|
|
n = 0; /* already collecting, don't do anything */
|
|
|
|
else {
|
|
|
|
collecting = 1;
|
|
|
|
n = collect(NUM_GENERATIONS - 1);
|
|
|
|
collecting = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
2001-08-29 21:05:51 -03:00
|
|
|
/* for debugging */
|
2003-04-17 14:29:22 -03:00
|
|
|
void
|
|
|
|
_PyGC_Dump(PyGC_Head *g)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
|
|
|
_PyObject_Dump(FROM_GC(g));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* extension modules might be compiled with GC support so these
|
|
|
|
functions must always be available */
|
|
|
|
|
2002-04-11 23:41:03 -03:00
|
|
|
#undef PyObject_GC_Track
|
|
|
|
#undef PyObject_GC_UnTrack
|
|
|
|
#undef PyObject_GC_Del
|
|
|
|
#undef _PyObject_GC_Malloc
|
|
|
|
|
2001-08-29 21:05:51 -03:00
|
|
|
void
|
2002-04-11 23:41:03 -03:00
|
|
|
PyObject_GC_Track(void *op)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
|
|
|
_PyObject_GC_TRACK(op);
|
|
|
|
}
|
|
|
|
|
2002-04-11 23:41:03 -03:00
|
|
|
/* for binary compatibility with 2.2 */
|
2001-08-29 21:05:51 -03:00
|
|
|
void
|
2002-04-11 23:41:03 -03:00
|
|
|
_PyObject_GC_Track(PyObject *op)
|
|
|
|
{
|
|
|
|
PyObject_GC_Track(op);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
PyObject_GC_UnTrack(void *op)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
2002-07-07 02:13:56 -03:00
|
|
|
/* Obscure: the Py_TRASHCAN mechanism requires that we be able to
|
|
|
|
* call PyObject_GC_UnTrack twice on an object.
|
|
|
|
*/
|
2002-05-21 12:53:24 -03:00
|
|
|
if (IS_TRACKED(op))
|
2002-03-28 16:34:59 -04:00
|
|
|
_PyObject_GC_UNTRACK(op);
|
2001-08-29 21:05:51 -03:00
|
|
|
}
|
|
|
|
|
2002-04-11 23:41:03 -03:00
|
|
|
/* for binary compatibility with 2.2 */
|
|
|
|
void
|
|
|
|
_PyObject_GC_UnTrack(PyObject *op)
|
|
|
|
{
|
|
|
|
PyObject_GC_UnTrack(op);
|
|
|
|
}
|
|
|
|
|
2001-08-29 21:05:51 -03:00
|
|
|
PyObject *
|
2002-04-11 23:41:03 -03:00
|
|
|
_PyObject_GC_Malloc(size_t basicsize)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
|
|
|
PyObject *op;
|
2006-04-11 09:14:09 -03:00
|
|
|
PyGC_Head *g = (PyGC_Head *)PyObject_MALLOC(
|
|
|
|
sizeof(PyGC_Head) + basicsize);
|
2001-08-29 21:05:51 -03:00
|
|
|
if (g == NULL)
|
2002-06-06 20:23:55 -03:00
|
|
|
return PyErr_NoMemory();
|
2002-07-01 21:52:30 -03:00
|
|
|
g->gc.gc_refs = GC_UNTRACKED;
|
2002-05-04 02:35:20 -03:00
|
|
|
generations[0].count++; /* number of allocated GC objects */
|
|
|
|
if (generations[0].count > generations[0].threshold &&
|
2001-08-29 21:05:51 -03:00
|
|
|
enabled &&
|
2002-05-04 02:35:20 -03:00
|
|
|
generations[0].threshold &&
|
2001-08-29 21:05:51 -03:00
|
|
|
!collecting &&
|
|
|
|
!PyErr_Occurred()) {
|
|
|
|
collecting = 1;
|
2002-05-04 02:35:20 -03:00
|
|
|
collect_generations();
|
2001-08-29 21:05:51 -03:00
|
|
|
collecting = 0;
|
|
|
|
}
|
|
|
|
op = FROM_GC(g);
|
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
_PyObject_GC_New(PyTypeObject *tp)
|
|
|
|
{
|
2002-04-11 23:41:03 -03:00
|
|
|
PyObject *op = _PyObject_GC_Malloc(_PyObject_SIZE(tp));
|
2002-04-27 22:57:25 -03:00
|
|
|
if (op != NULL)
|
|
|
|
op = PyObject_INIT(op, tp);
|
|
|
|
return op;
|
2001-08-29 21:05:51 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
PyVarObject *
|
2006-02-15 13:27:45 -04:00
|
|
|
_PyObject_GC_NewVar(PyTypeObject *tp, Py_ssize_t nitems)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
2002-04-11 23:41:03 -03:00
|
|
|
const size_t size = _PyObject_VAR_SIZE(tp, nitems);
|
|
|
|
PyVarObject *op = (PyVarObject *) _PyObject_GC_Malloc(size);
|
2002-04-27 22:57:25 -03:00
|
|
|
if (op != NULL)
|
|
|
|
op = PyObject_INIT_VAR(op, tp, nitems);
|
|
|
|
return op;
|
2001-08-29 21:05:51 -03:00
|
|
|
}
|
|
|
|
|
|
|
|
PyVarObject *
|
2006-02-16 10:56:14 -04:00
|
|
|
_PyObject_GC_Resize(PyVarObject *op, Py_ssize_t nitems)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
2001-10-07 00:54:51 -03:00
|
|
|
const size_t basicsize = _PyObject_VAR_SIZE(op->ob_type, nitems);
|
2001-08-29 21:05:51 -03:00
|
|
|
PyGC_Head *g = AS_GC(op);
|
2006-04-11 09:14:09 -03:00
|
|
|
g = (PyGC_Head *)PyObject_REALLOC(g, sizeof(PyGC_Head) + basicsize);
|
2001-08-29 21:05:51 -03:00
|
|
|
if (g == NULL)
|
|
|
|
return (PyVarObject *)PyErr_NoMemory();
|
|
|
|
op = (PyVarObject *) FROM_GC(g);
|
2001-10-06 18:27:34 -03:00
|
|
|
op->ob_size = nitems;
|
2001-08-29 21:05:51 -03:00
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2002-04-11 23:41:03 -03:00
|
|
|
PyObject_GC_Del(void *op)
|
2001-08-29 21:05:51 -03:00
|
|
|
{
|
|
|
|
PyGC_Head *g = AS_GC(op);
|
2002-05-21 12:53:24 -03:00
|
|
|
if (IS_TRACKED(op))
|
2001-08-29 21:05:51 -03:00
|
|
|
gc_list_remove(g);
|
2002-05-04 02:35:20 -03:00
|
|
|
if (generations[0].count > 0) {
|
|
|
|
generations[0].count--;
|
2001-08-29 21:05:51 -03:00
|
|
|
}
|
2002-04-11 23:41:03 -03:00
|
|
|
PyObject_FREE(g);
|
2001-08-29 21:05:51 -03:00
|
|
|
}
|
|
|
|
|
2002-04-11 23:41:03 -03:00
|
|
|
/* for binary compatibility with 2.2 */
|
|
|
|
#undef _PyObject_GC_Del
|
|
|
|
void
|
|
|
|
_PyObject_GC_Del(PyObject *op)
|
|
|
|
{
|
|
|
|
PyObject_GC_Del(op);
|
|
|
|
}
|