[Python-Dev] Fwd: Removal of GIL through refcounting removal. (original) (raw)

Giovanni Bajo rasky at develer.com
Sun Nov 2 14:26:47 CET 2008

On Sun, 02 Nov 2008 10:21:26 +1000, Nick Coghlan wrote:

Maciej Fijalkowski wrote:

...

We know it is the plan for PyPy to work in this way, and also that Jython and Ironpython works like that (using the host vm's GC), so it seems to be somehow agreeable with the python semantics (perhaps not really with del but they are not really nice anyway).

PyPy has a semi-advanced generational moving gc these days. It's not as well tuned as JVMs one, but it works quite well. Regarding semantic changes, there is a couple which as far as I remember are details which you should not rely on anyway (At least some of the below applies also for Jython/IronPython): * del methods are not called immediately when object is not in a cycle * all objects are collected, which means objects in cycles are broken in arbitrary order (gc.garbage is always empty), but normal ordering is preserved. * id's don't always resemble address of object in memory * resurrected objects have del called only once in total. Yep, I'm pretty those are all even explicitly documented as implementation details of CPython (PEP 343's with statement was largely added as a cross-implementation way of guaranteeing prompt cleanup of resources like file handles without relying on CPython's del semantics or writing your own try/finally statements everywhere).

Though there is a fair difference from "explicitly documented as implementation details" and the real-world code where programmers have learnt to save code lines by relying on the reference-counting semantics.

[[ my 0.2: it would be a great loss if we lose reference-counting semantic (eg: objects deallocated as soon as they exit the scope). I would bargain that for a noticable speed increase of course, but my own experience with standard GCs from other languages has been less than stellar. ]]

Giovanni Bajo Develer S.r.l. http://www.develer.com

More information about the Python-Dev mailing list