Neil Schemenauer <nas at python.ca> writes: > Douglas Alan wrote: > > (1) Why does it use the rather unusual algorithm it does, rather > > than a more typical mark and sweep? The per-object storage cost > > for the extra reference count is surely greater than the bit or > > two required for a typical mark and sweep. > Mark and sweep requires that you find all root pointers. That's > difficult to do if you want it to be portable and allow for easy > embedding and extension of the language. What's more to the point, I think, is that traditional M&S works by assuming that an object is garbage unless it can prove that it's not. This requires all objects to be scrupulous about providing enough information for the collector to be able to find all references embedded within them. Existing Python extension modules do not provide this information about their objects, so for backwards compatibility, Python's GC has to work the other way around, and assume that an object is not garbage unless it can prove that it is. I expect that this requirement is the reason for the algorithm used. -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand To get my email address, please visit my web page: http://www.cosc.canterbury.ac.nz/~greg
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