[Python-Dev] GC Changes

Justin Tulloss tulloss2 at uiuc.edu
Mon Oct 1 08:43:04 CEST 2007


Hello,

I've been doing some tests on removing the GIL, and it's becoming clear that
some basic changes to the garbage collector may be needed in order for this
to happen efficiently. Reference counting as it stands today is not very
scalable.

I've been looking into a few options, and I'm leaning towards the
implementing IBMs recycler GC
(http://www.research.ibm.com/people/d/dfb/recycler-publications.html
) since it is very similar to what is in place now from the users'
perspective. However, I haven't been around the list long enough to really
understand the feeling in the community on GC in the future of the
interpreter. It seems that a full GC might have a lot of benefits in terms
of performance and scalability, and I think that the current gc module is of
the mark-and-sweep variety. Is the trend going to be to move away from
reference counting and towards the mark-and-sweep implementation that
currently exists, or is reference counting a firmly ingrained tradition?

On a more immediately relevant note, I'm not certain I understand the full
extent of the gc module. From what I've read, it sounds like it's fairly
close to a fully functional GC, yet it seems to exist only as a
cycle-detecting backup to the reference counting mechanism. Would somebody
care to give me a brief overview on how the current gc module interacts with
the interpreter, or point me to a place where that is done? Why isn't the
mark-and-sweep mechanism used for all memory management?

Thanks a lot!

Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20071001/08f40ae5/attachment.htm 


More information about the Python-Dev mailing list