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

[Antoine Pitrou]

On Sat, 15 Jun 2013 22:22:33 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

The small object allocator *already* delegates those operations
directly to the OS. You don't need a separate API to do it by hand.

> 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.

Which custom allocators?

> > 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).

Actually, I'm sure almost everyone *is* satisfied with the status quo
here (witness the total absence of bug reports on the matter). Victor's
patch addresses a rare concern compared to the common use cases of
CPython.

And I'm not even sure what "faux simplicity" you are talking about.
What is the supposed complexity that this API is supposed to address?
Why do we need two different pairs of hook-setting functions, rather
than letting each function set / get all hooks at once? And why the
private API functions for setting arena allocators?

Memory allocation APIs are a fundamental part of the C API that many
extension writers have to understand and deal with. I'm opposed to
gratuitous complication when the use cases are not compelling.

Regards

Antoine.