Jeremy covered already most of it, so I'll only address specific points: > and I think that the current gc > module is of the mark-and-sweep variety.
That is incorrect. It's two phases, but in the first phase, it isn't "mark", but "count", and in the second phase, it's not "sweep" but "break". To "count" means to count the number of references to an object, and to "break" means to break the cycles at selected places, expecting that reference counting will actually cause objects to become released. > 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? For the CPython implementation, there is no trend. The language spec explicitly states that automatic memory management is unspecified and implementation-defined, yet people rely on reference counting in many programs. That is not the reason to kick it out, though - it stays around because a true mark-and-sweep algorithm cannot be implemented on top of the current object API (as Jeremy explains, there is no notion of root objects in the VM). > 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? What is "this" that is done? The collector? I think you found Modules/gcmodule.c already. Take particular notice of the tp_traverse and tp_clear type methods. > Why isn't the mark-and-sweep mechanism used for all memory > management? See above - it's not implementable, because the root objects get not tracked. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
