[Python-Dev] Fwd: Removal of GIL through refcounting removal.

Maciej Fijalkowski fijall at gmail.com
Sat Nov 1 21:12:56 CET 2008

> ...

> 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.

I think for example last one is so obscure detail that if someone
relies on it it's his problem :)


More information about the Python-Dev mailing list