Uh oh!
There was an error while loading. Please reload this page.
[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.
bedevere-bot
commented
Apr 1, 2025
🤖 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. |
nedbat
commented
Apr 14, 2025
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. |
colesbury
commented
Apr 14, 2025
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.