Feature or enhancement
Mimalloc was added as an allocator in #90815. The --disable-gil builds need further integration with mimalloc, as well as some modifications to mimalloc to support thread-safe garbage collection in --disable-gil builds and the dictionary accesses that mostly avoid locking.
These changes can be split up across multiple PRs.
- Currently, when mimalloc is enabled, all allocations go to the default heap. This is fine for
PyMem_Malloc calls, but we need separate heaps for PyObject_Malloc and PyObject_GC_New. We should associate some mi_heap_ts with each PyThreadState. Every PyThreadState needs four heaps: one for PyMem_Malloc, one for non-GC objects (via PyObject_Malloc), one for GC objects with managed dicts (extra pre-header) and one for GC objects without a managed dict. We need some way to know which heap to use in _PyObject_MiMalloc. There's not a great way to do this, but I suggest adding something like a "current pyobject heap" variable to PyThreadState. It should generally point to the PyObject_Malloc heap, but PyObject_GC_New should temporarily override it to point to the correct GC heap when called
--disable-gil should imply --with-mimalloc and require mimalloc (i.e., disallow changing the allocator with PYTHONMALLOC).- We should tag each mi_heap_t and mi_page_t with a number identifying which type of allocation it's associated with. This is important for when pages are abandoned (i.e., when a thread exits with live blocks remaining) and the page is no longer associated with a heap. The GC still needs to identify which of those pages store GC-enabled objects. (see colesbury/nogil-3.12@d447b69)
- When claiming a page from an abandoned segment, mimalloc should associate it with the correct heap from the current thread. In other words, pages that store GC-enabled objects should only be put back in the correct GC heap.
cc @DinoV
Linked PRs
Feature or enhancement
Mimalloc was added as an allocator in #90815. The
--disable-gilbuilds need further integration with mimalloc, as well as some modifications to mimalloc to support thread-safe garbage collection in--disable-gilbuilds and the dictionary accesses that mostly avoid locking.These changes can be split up across multiple PRs.
PyMem_Malloccalls, but we need separate heaps forPyObject_MallocandPyObject_GC_New. We should associate somemi_heap_ts with eachPyThreadState. Every PyThreadState needs four heaps: one for PyMem_Malloc, one for non-GC objects (via PyObject_Malloc), one for GC objects with managed dicts (extra pre-header) and one for GC objects without a managed dict. We need some way to know which heap to use in_PyObject_MiMalloc. There's not a great way to do this, but I suggest adding something like a "current pyobject heap" variable to PyThreadState. It should generally point to thePyObject_Mallocheap, butPyObject_GC_Newshould temporarily override it to point to the correct GC heap when called--disable-gilshould imply--with-mimallocand require mimalloc (i.e., disallow changing the allocator withPYTHONMALLOC).cc @DinoV
Linked PRs
--disable-gilbuilds #112883