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

Nick Coghlan ncoghlan at gmail.com
Sun Nov 2 01:21:26 CET 2008

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

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list