[Python-Dev] Moving forward on the object memory API

Neil Schemenauer nas@python.ca
Mon, 1 Apr 2002 06:54:57 -0800

Guido van Rossum wrote:
> > Next, we base PyObject_{MALLOC,REALLOC,FREE} on pymalloc.  Basically:
> > 
> >     #ifdef WITH_PYMALLOC
> >     #define PyObject_MALLOC(n)      _PyMalloc_Malloc(n)
> >     #define PyObject_REALLOC(op, n) _PyMalloc_Realloc((void *)(op), (n))
> >     #define PyObject_FREE(op)       _PyMalloc_Free((void *)(op))
> >     #else
> >     #define PyObject_MALLOC(n)      PyMem_MALLOC(n)
> >     #define PyObject_REALLOC(op, n) PyMem_REALLOC((void *)(op), (n))
> >     #define PyObject_FREE(op)       PyMem_FREE((void *)(op))
> >     #endif
> Couldn't these always use the first set of definitions?  I suppose
> that when configured --without-pymalloc, _PyMalloc_Malloc and friends
> are aliases for malloc?

No, the _PyMalloc_* functions are only available if pymalloc is enabled.
We could make it so that the _PyMalloc_* functions are always available.
People who don't use pymalloc would take a performance hit though.

> Also, do we need these at all?  (Hm, I must be missing something, but
> I can't figure what.)

Do you mean PyObject_{MALLOC,REALLOC,FREE}?  I think we do.  There needs
to be a way to allocate memory using the object allocator.  I like
PyObject_MALLOC better than PyMalloc_MALLOC and it was also present in
previous releases.

> > PyMem_DEL and PyMem_Free need to call pymalloc:
> > 
> >     #define PyMem_DEL(op) PyObject_FREE(op)
> Why not _PyMalloc_Malloc?

See above (pymalloc may be disabled).

> > We go through the source and replace all the PyMem_* function calls with
> > the equivalent PyMem_* macro calls and replace PyMem_DEL with
> > PyMem_FREE.
> Or PyObject_Del (depending on the situation)?

Nope.  There should be no place in the CVS source that calls PyMem_DEL
when it should be PyObject_Del.

> Is there a difference between PyMem_MALLOC and PyMem_NEW?  Between
> PyMem_REALLOC and PyMem_RESIZE?  If there isn't, shouldn't we
> recommend one set and deprecate the other?  I think I like the NEW
> family best (it's got seniority).

NEW and RESIZE are type based while MALLOC and REALLOC work by bytes.  I
think you need them both.

> I suppose the patches that changed PyObject_New into PyMalloc_New can
> be reverted now?