[Patches] GC infrastructure patch 1 (tp_recurse, tp_clear)

[M.-A. Lemburg]

Neil Schemenauer wrote:
> 
> On Thu, Jun 15, 2000 at 10:39:24AM +0200, M.-A. Lemburg wrote:
> > Some questions:
> >
> > * what's the impact of having GC enabled for the class of
> >   well bahaved programs (those which do not create cyclic
> >   garbage) ?
> 
> There is the memory overhead of the PyGCInfo struct that is
> prefixed to all objects with the GC type flag set (~ 3 words).
> By default, the collector runs after X net new object allocations
> (this can be tuned or turned off).  Because of the generational
> collection, the collector usually only looks at a few objects
> when it runs.  There is also some overhead inserting and removing
> GC objects into the linked list of all GC objects.

Hmm, I guess we'd need to add some more free lists for
small containers then... tuples already have such a list,
adding something similar to lists and dictionaries would
probably be worthwhile too, both to reduce GC overhead
and to boost performance (small lists and dicts being are
created/deleted quite often).

I have a patch for dicts... anybody have something similar
for lists ?

I also have a free list implementation for Python instances
(which also keeps the instance dicts allocated), BTW. Any
interest in this ?

> > * would it be possible to disable automatic collection and
> >   implement a custom collection invocation scheme ?
> 
> It is possible to disable it (gc.set_threshold(0)).  I'm not sure
> what you mean by custom scheme.  You can call gc.collect()
> explicitly if thats what you mean.

Right, that's what I meant. I would like to implement
a different scheme in a server I run in my app: it would
run the GC collector after having completed processing
a request while waiting for the next request, rather than
during a request.
 
> > * what would an extension type have to do/implement to
> >   participate in GC ?
> 
> This is documented in objimp.h:
> 
> /* To make a new object participate in garbage collection use
>    PyObject_{New, VarNew, Del} to manage the memory.  Set the type flag
>    Py_TPFLAGS_GC and define the type method tp_recurse.  You should also
>    add the method tp_clear if your object is mutable.  Include
>    PyGC_INFO_SIZE in the calculation of tp_basicsize.  Call
>    PyObject_GC_Init after the pointers followed by tp_recurse become
>    valid (usually just before returning the object from the allocation
>    method.  Call PyObject_GC_Fini before those pointers become invalid
>    (usually at the top of the deallocation method).  */

That seems easy enough ;-)
 
> > * would an extension compiled with GC still work together
> >   with an interpreter which is not (and vice-versa) ?
> 
> Yes.  An extension compiled with GC enabled will work with a
> non-GC interpreter and the other way around.  For an extension
> type to participate in GC it must be compiled with GC enabled and
> be used with a GC interpreter.

Great :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/