[Python-Dev] GC Changes

["Martin v. Löwis"]

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