[Patches] GC infrastructure patch 2 (type changes)

[Greg Stein]

On Thu, Jun 15, 2000 at 06:05:48AM +0300, Moshe Zadka wrote:
> On Wed, 14 Jun 2000, Neil Schemenauer wrote:
> 
> > This patch modifies the type structures of objects that
> > participate in GC.  The object's tp_basicsize is increased when
> > GC is enabled.  GC information is prefixed to the object to
> > maintain binary compatibility.  GC objects also define the
> > tp_flag Py_TPFLAGS_GC.
> 
> a) See my other a)
> 
> b) in 
> 
> + /* Objects which participate in garbage collection (see objimp.h) */
> + #ifdef WITH_CYCLE_GC
> + #define Py_TPFLAGS_GC (1L<<2)
> + #else
> + #define Py_TPFLAGS_GC 0
> + #endif
> 
> What's wrong with defining Py_TPFLAGS_GC unconditionally?

Agreed, here. This is similar to the slots thing. Define it unconditionally.
It isn't like ANY other extension can ever use that flag bit for anything
else. That bit, from here on, means "GC".

Not sure on the overall patch. It would be much nicer to simply include the
GC fields into the object. Essentially, have something like this:

typedef struct {
    PyObject_VAR_HEAD_GC
    PyObject **ob_item;
} PyListObject;

#define PyObject_VAR_HEAD_GC \
    PyObject_HEAD_GC \
    int ob_size;

#define PyObject_HEAD_GC \
    my_three_items
    PyObject_HEAD
    
In the allocation of these, just do:

    ptr = (PyListObject *)some_kinda_alloc(...)
    ob = (PyObject *)&ptr->refcnt;

Of course, ob+sizeof(PyListObject) doesn't really point to just after the
structure. Not sure if that is good or bad.

Hmm. Probably bad. Never mind the above suggestion... :-)
[ but left as a possible stimulus for others ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/