Showing content from http://mail.python.org/pipermail/python-dev/attachments/20071001/ee5746af/attachment.htm below:
On 01/10/2007, <b class="gmail_sendername">Justin Tulloss</b> <<a href="mailto:tulloss2@uiuc.edu">tulloss2@uiuc.edu</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="gmail_quote"></span>Hello,<br><br>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.
<br><br>I've been looking into a few options, and I'm leaning towards the implementing IBMs recycler GC (<a href="http://www.research.ibm.com/people/d/dfb/recycler-publications.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.research.ibm.com/people/d/dfb/recycler-publications.html
</a>) 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?
<br><br>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?
</blockquote><div><br>The cyclic GC is just too slow to react and makes programmers mad.<br><br>For instance, in PyGtk we had a traditional problem with gtk.gdk.Pixbuf, which is basically an object that wraps a raw RGB image. When users deleted such an object, which could sometimes comprise tens or hundreds of megabytes, the memory was not relased until much much later. That kind of code ended up having to manually call
gc.collect() to fix what was perceived by most programmers as a "memory leak", which kind of defeats the purpose of a garbage collector. This happened because PyGtk used to rely on the cyclic GC doing its work. Thankfully we moved away from that and now simple reference counting can free a Pixbuf in most cases.
<br><br>The cyclic GC is a very useful system, but it should only be used in addition to, not instead of, reference counting. At least that's my personal opinion...<br></div></div><br>-- <br>Gustavo J. A. M. Carneiro
<br>INESC Porto, Telecommunications and Multimedia Unit<br>"The universe is always one step beyond logic." -- Frank Herbert
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4