If there are many untracked tuples, the GC will run too often, resulting in poor performance. The fix is to include untracked tuples in the "long lived" object count. The number of frozen objects is also now included since the free-threaded GC must scan those too.
Closed
bugs and security fixes
pre-release feature fixes, bugs and security fixes
labels
Dec 11, 2025
Subtract the objects that are unreachable and add back the ones that are resurrected. This likely doesn't matter in most cases but if the GC is freeing a lot of cyclic garbage then we don't want to over count the long lived objects.
…ong-lived
nascheme marked this pull request as ready for review
December 11, 2025 17:23
nascheme added a commit to nascheme/cpython that referenced this pull request
Dec 12, 2025
…ythongh-142562) If there are many untracked tuples, the GC will run too often, resulting in poor performance. The fix is to include untracked tuples in the "long lived" object count. The number of frozen objects is also now included since the free-threaded GC must scan those too. (cherry picked from commit e38967e )
fatelei pushed a commit to fatelei/cpython that referenced this pull request
Dec 12, 2025
…h-142562) If there are many untracked tuples, the GC will run too often, resulting in poor performance. The fix is to include untracked tuples in the "long lived" object count. The number of frozen objects is also now included since the free-threaded GC must scan those too.
nascheme added a commit that referenced this pull request
Dec 12, 2025
) (gh-142617) If there are many untracked tuples, the GC will run too often, resulting in poor performance. The fix is to include untracked tuples in the "long lived" object count. The number of frozen objects is also now included since the free-threaded GC must scan those too. (cherry picked from commit e38967e )
This was referenced
May 6, 2026Open
Merged