[Python-Dev] Removing the GIL (Me, not you!) (original) (raw)

Jason Orendorff jason.orendorff at gmail.com
Wed Sep 12 16:47:33 CEST 2007

On 9/12/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:

Now we are getting into details: you do NOT have to lock an object to modify its reference count. An atomic increment/decrement operation is enough.

One could measure the performance hit incurred by using atomic operations for refcounting by hacking a few macros -- right?

Deferred reference counting (DRC for short) might help... http://www.memorymanagement.org/glossary/d.html#deferred.reference.counting

I can explain a little more how this works if anyone's interested. DRC basically eliminates reference counting for locals--that is, pointers from the stack to an object. An object becomes refcounted only when some other object gets a pointer to it. The drawback is that destructors aren't called quite as promptly as in true refcounting. (They're still called in the right order, though--barring cycles, an object's destructor is called before its children's destructors.)

What counts as "stack" is up to the implementation; typically it means "the C stack". This could be used to eliminate most refcounting in C code, although listobject.c would keep it. The amount of per-platform assembly code needed is surprisingly small (and won't change, once you've written it--the Tamarin JavaScript VM does this).

You could go further and treat the Python f_locals and interpreter stack as "stack". I think this would eliminate all refcounting in the interpreter. Of course, it complicates matters that f_locals is actually an object visible from Python.

Just a thought, not a demand, please don't flame me, -j

More information about the Python-Dev mailing list