Skip to content

mimalloc: additional integration and changes for --disable-gil builds #112532

Closed
@colesbury

Description

@colesbury

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

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions