Cyclops 0.9.4

[Tim Peters]

[Greg Ewing]
> Seems to me that Cyclops (or any other such thing
> implemented in pure Python) is incapable of finding
> what you *really* want to find -- which is groups
> of objects not reachable from anywhere.

1. That can't be done in C today either (Python has no internal way to find
all allocated objects, and there's no protocol to implement pointer-chasing
either).

2. Unless you're fighting a bug in the interpreter's reference-counting code
(very rare), those groups of unreachable objects necessarily contain cycles.
That's why Cyclops focuses on cycles.

3. They're really not what you're looking for either, in my experience.  All
forms of GC are mechanical approximations to what you really want:  that an
object go away when it *won't* be referenced again, not when it *can't* be
referenced again.  The latter is a conservative approximation to the former.

Most leaks I've seen are due to objects that are reachable, but where the
author didn't *expect* them to reachable.  Cyclops can help with that too,
by calling get_rootset() at the end and seeing which registered objects
still have a non-0 (adjusted) refcount that you were expecting to be
history.

That's the mode it's being used in with IDLE now:  things *are* still
reachable that nobody expects "should be" reachable.  What Cyclops can't do
(yet <wink>) is tell you from *where* they can be reached.  All it can say
for now is that they don't appear to be in cycles -- they're still reachable
"for some other" reason.

you-wanna-know-different-things-at-different-stages-ly y'rs  - tim