[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 :)
Cheers,
fijal
More information about the Python-Dev
mailing list