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

[Jason Orendorff]

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