[Python-3000] Delayed reference counting idea

Adam Olsen rhamph at gmail.com
Mon Sep 18 21:59:35 CEST 2006

On 9/18/06, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le lundi 18 septembre 2006 à 09:48 -0600, Adam Olsen a écrit :
> > * Bolt-on tracing GC such as Boehm-Demers-Weiser.  Totally unsupported
> > by the C standards and changes cache characteristics that CPython has
> > been designed with for years, likely with a very large performance
> > penalty.
> Has it been measured what cache effects reference counting entails ?
> With reference counting, each object is mutable from the point of view
> of the CPU cache (refcnt is always incremented and later decremented).
> This means almost every cache line containing Python objects - including
> functions, modules... - has to be written back when it is evicted, even
> if those objects are "constant".

I don't think there's ever been any measuring, just theorizing based
on some general benchmarks.  For example, it's likely that the cache
line containing the refcount is likely already loaded, when the type
point is loaded.

However, delayed reference counting could allow you to remove
incref/decref pairs, thereby avoiding the write entierly in some

> > * Delayed reference counting (save 10 or 20 INCREF/DECREF ops to a
> > buffer, then flush them all at once).  In theory, it would retain the
> > cache locality while amortizing locking needed for SMP machines.
> You would have to lock the buffer, wouldn't you?
> Unless you use per-CPU buffers.

I'm assuming per-CPU buffers.  You'd need a global lock to flush them.
 There's probably some more creative schemes, but they couldn't be
implemented quite so simply.

Adam Olsen, aka Rhamphoryncus

More information about the Python-3000 mailing list