[Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators

[Nick Coghlan]

On 15 June 2013 21:01, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 15 Jun 2013 03:54:50 +0200
> Victor Stinner <victor.stinner at gmail.com> wrote:
>> The addition of PyMem_RawMalloc() is motivated by the issue #18203
>> (Replace calls to malloc() with PyMem_Malloc()). The goal is to be
>> able to setup a custom allocator for *all* allocation made by Python,
>> so malloc() should not be called directly. PyMem_RawMalloc() is
>> required in places where the GIL is not held (ex: in os.getcwd() on
>> Windows).
>
> We already had this discussion on IRC and this argument isn't very
> convincing to me. If os.getcwd() doesn't hold the GIL while allocating
> memory, then you should fix it to hold the GIL while allocating memory.
>
> I don't like the idea of adding of third layer of allocation APIs. The
> dichotomy between PyObject_Malloc and PyMem_Malloc is already a bit
> gratuitous (i.e. not motivated by any actual real-world concern, as
> far as I can tell).

The only reason for the small object allocator to exist is because
operating system allocators generally aren't optimised for frequent
allocation and deallocation of small objects. You can gain a *lot* of
speed from handling those inside the application. As the allocations
grow in size, though, the application level allocator just becomes
useless overhead, so it's better to delegate those operations directly
to the OS.

However, it's still desirable to be able to monitor those direct
allocations in debug mode, thus it makes sense to have a GIL protected
direct allocation API as well. You could try to hide the existence of
the latter behaviour and treat it as a private API, but why? For
custom allocators, it's useful to be able to *ensure* you can bypass
CPython's small object allocator, rather than having to rely on it
being bypassed for allocations above a certain size.

> As for the debug functions you added: PyMem_GetRawAllocators(),
> PyMem_SetRawAllocators(), PyMem_GetAllocators(), PyMem_SetAllocators(),
> PyMem_SetupDebugHooks(), _PyObject_GetArenaAllocators(),
> _PyObject_SetArenaAllocators(). Well, do we need all *7* of them? Can't
> you try to make that 2 or 3?

Faux simplicity that is achieved only by failing to model a complex
problem domain correctly is a bad idea (if we were satisfied with
that, we could stick with the status quo).

The only question mark in my mind is over the GIL-free raw allocation
APIs. I think it makes sense to at least conditionally define those as
macros so an embedding application can redirect *just* the allocations
made by the CPython runtime (rather than having to redefine
malloc/realloc/free when building Python), but I don't believe the
case has been adequately made for making the raw APIs configurable at
runtime. Dropping that aspect would at least eliminate the
PyMem_(Get|Set)RawAllocators() APIs.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia