[Python-Dev] C API for gc.enable() and gc.disable()

["Martin v. Löwis"]

> XEmacs implements this strategy in a way which is claimed to give
> constant amortized time (ie, averaged over memory allocated).

See my recent proposal. The old trick is to do reorganizations
in a fixed fraction of the total size, resulting in a per-increase
amortized-constant overhead (assuming each reorganization takes time
linear with total size).

> However, isn't the real question whether there is memory pressure or
> not?  If you've got an unloaded machine with 2GB of memory, even a 1GB
> spike might have no observable consequences.  How about a policy of
> GC-ing with decreasing period ("time" measured by bytes allocated or
> number of allocations) as the fraction of memory used increases,
> starting from a pretty large fraction (say 50% by default)?

The problem with such an approach is that it is very difficult to
measure. What to do about virtual memory? What to do about other
applications that also consume memory?

On some systems (Windows in particular), the operating system indicates
memory pressure through some IPC mechanism; on such systems, it might
be reasonable to perform garbage collection (only?) when the system asks
for it. However, the system might not ask for GC while the swap space
is still not exhausted, meaning that the deferred GC would take a long
time to complete (having to page in every object).

> Nevertheless, I think the real solution has to be for Python
> programmers to be aware that there is GC, and that they can tune it.

I don't think there is a "real solution". I think programmers should
abstain from complaining if they can do something about the problem
in their own application (unless the complaint is formulated as a
patch) - wait - I think programmers should abstain from complaining,
period.

Regards,
Martin