Repository navigation
Use per-thread freelists in --disable-gil builds #111968
Description
Activity
Hi!
I'm new here, but if you don't mind I would like to take that issueI don't think there are any good issues right now that are scoped out and not blocked on other work.
Okay, got it. Thank you
@colesbury I would like to take a look at this issue, Is there any pending issues that are related to this issue?
#113584 will introduce seamless management of freelists that runtimes do not need to care about the implementation detail :)
Loadinggraph TD; PerThread --> FreeList; PerInterpreter --> FreeList; GC -- if free-threaded --> gc_freethreading; GC -- if default build --> gc_gil; gc_freethreading --> PerThread; gc_gil --> PerInterpreter; _PyFreeListState -- if free-threaded --> PerThread; _PyFreeListState -- if default build --> PerInterpreter; Runtime -- _PyFreeListState_GET --> _PyFreeListState; list --> Runtime; tuple --> Runtime; slice --> Runtime; float --> Runtime; dict --> Runtime; generator --> Runtime; PyContext --> Runtime;Reacted by Erlend E. AaslandReacted by Erlend E. Aasland and Łukasz Langa73 remaining items
- added 10 commits that reference this issue
on Sep 2, 2024 - added a commit that references this issue
on Jul 15, 2025
Feature or enhancement
CPython uses freelists for frequently allocated Python objects, like
dict,list, andslice. There freelists are generally stored in the per-interpreter state, which is not thread-safe without the GIL. In--disable-gilbuilds, the freelists should be stored in the per-thread state (i.e.,PyThreadState). I think we probably want to keep the freelists in the interpreter state for the default build. This will probably require some refactoring.Freelists:
floatslice(slice_cache)tuplelistdict(PyDictKeysObjectandPyDictObject)generator(value_freelistandasend_freelist)PyContextFor context, here are similar changes in the
nogil-3.12fork, but I expect the changes in CPython 3.13 to be a bit different:Linked PRs