Circular references (was: Defining VCL-like framework for Py

[Gordon McMillan]

Yoo C. Chung writes:

> Gordon McMillan writes:
> 
> > But ref counting depends only on what goes on inside my process. GC
> > is influenced by other things.
> 
> For example?

Usually, GC is kicked off when it decides memory is getting short. So 
what else is running may influence when you objects get collected.

> Depending on the implementation, garbage collection can always occur
> at exactly certain fixed points for single threaded apps.  (This
> sometimes eases the implementation of a garbage collector, since I
> can set conditional breakpoints to see just which part is allocating
> a piece of misbehaving memory.)
> 
> On the other hand, garbage collection in multithreaded apps is
> almost never deterministic, but the same can be said for reference
> counting. In addition, reference counting could suffer a large
> performance hit in multithreaded apps since every update must be
> protected by a mutex in a naive implementation.

Granted GC can take all kinds of forms, but rarely is slowness of ref 
counting used as an argument in the debate!  Mutexes for shared data 
are necessary in a GC'd system, too, so I don't see how that makes 
any difference.
 
> Not that I'm advocating the use of garbage collection in Python. 
> I'm just pointing out that garbage collection can be deterministic
> (though maybe not in the way people want it to be).

And of course part of the secret of creating a Java benchmark is 
making sure GC doesn't happen 'till the "end" time has been taken.
Now _that's_ deterministic <wink>.


- Gordon