[Python-Dev] impact of cycle gc...

[Vladimir Marangozov]

Neil Schemenauer wrote:
> 
> On a related note, I would like to cleanup the PyGC_{NEW,
> VAR_NEW} macros but I can't figure out a way to transform this
> code into a macro:
> 
>     op = PyObject_MALLOC(sizeof(PyGCInfo) + _PyObject_SIZE(tp));
>     if (op)
>         op = PyGC_OBJ((PyGCInfo *)op);

The correct thing to do, IMO, is to reflect the sizeof(PyGCInfo)
mem increment in the tp_basicsize slot of the type object. Thus, we can
reuse the current PyObject_New/NEW code, which boils down to
PyObject_MALLOC(_PyObject_SIZE(tp)).  There is no need for PyGC_NEW/NEW_VAR.

This would imply some additional changes to PyObject_Init when the
GC_FLAG is set for a given typeobj.

I had a closer look at the patch today. It looks good, but I think it
needs some more work for a smooth integration with the existing APIs.
There's room for optimisations (there are lots of function calls in there,
so I am not surprised about the performance hit), but they'll come
later on, once the big chunks of the patch fit in their places.

One thing that bothered me is that the current gc object allocation
code won't fly with C++, where the object storage is allocated (and its
size is computed) automatically. There is no PyObject_New, and a C++
object constructor is supposed to begin with PyObject_Init.

Another thing is the function names: PyGC_NEW, PyGC_Info, PyGC_Insert, etc.
It would be better if they reflect the fact that we're talking about GC
on PyObjects, and not about GC in general (on arbitrary mem chunks).

I would suggest renaming them along these lines:

PyGC_Info -> PyGC_ObjectHead
PyGC_Insert -> PyGC_ObjectInit
PyGC_Remove -> PyGC_ObjectFini
...

All this needs some more thought though...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252