[3.13] gh-131988: Fix a multithreaded scaling regression #131989
Conversation
The 3.13 free threaded build immortalizes certain objects to avoid reference count contention. In pythongh-127114 the condition was unintentionally changed to happen when the first thread was created instead of the first non-main thread. The `interp->gc.immortalize` field is then cleared again during `_PyGC_Init()`. Change the condition so that we check if we should immortalize objects using deferred reference counting whenever a non-main thread is created.
|
🤖 New build scheduled with the buildbot fleet by @colesbury for commit 22349fd 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131989%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again. |
|
All commit authors signed the Contributor License Agreement. |
|
The coverage.py nightly test suite has been failing on 3.13t since this commit. In particular, the test that my C extension isn't leaking code objects. It looks like now we expect code objects will never be reclaimed, and this change is only on 3.13 and will not be applied to 3.14, is that right? I can adjust my tests if so. |
Yes, that's right |
The 3.13 free threaded build immortalizes certain objects to avoid reference count contention. In gh-127114 the condition was unintentionally changed to happen when the first thread was created instead of the first non-main thread. The
interp->gc.immortalizefield is then cleared again during_PyGC_Init().Change the condition so that we check if we should immortalize objects using deferred reference counting whenever a non-main thread is created.