Python and Boehm-Demers GC, I have code.

Robin Becker robin at jessikat.demon.co.uk
Sun Jul 18 06:36:25 EDT 1999


In article <000e01bed0fa$04316520$36a02299 at tim>, Tim Peters
<tim_one at email.msn.com> writes
>[Tim, speculates on why pystone/pybench aren't much affected by BDW w/
> refcounting left on]
>
...
>So screw it <wink>.  Find someone with an important program that's leaking
>memory and see whether this fixes *that*.  This (not speed) is BDW's real
>strength anyway.  Chalk up a few victories there, and selling will be much
>easier.
>
>A cautionary tale:  Over the past month I've been poking away at tracking
>leaks in IDLE.  After building a capable-enough cycle-finding tool (a
>feature-bloated but much faster offshoot of Lars's Plumbo.py), I found
>cycles all over the place.  As things turned out, though, hardly any of them
>could be considered trash!  The way functions point to their module globals,
>which in turn point to imported modules, some of which eventually point into
>sys, from whose sys.modules everthing can be reached ... an isolated cycle
>was very rare indeed.
>
>It came as a real surprise to me that "real GC" wouldn't have helped.  This
>may be a particularly nasty problem for GUI programs, so I'm not too quick
>to generalize.  OTOH, don't be too quick to discount it either <wink>.
>
...
very interesting; I'm spending a bit of time on Zope at the moment. This
if anything will be a long running thing which shouldn't leak memory.
Any chance of an analysis? Or the (I'm sure all the features are good)
version of plumbo?
-- 
features-to-one-are-bugs-to-others-ly yrs
Robin Becker




More information about the Python-list mailing list