gh-132657: Add maybe_enable_deferred_ref_count(). by nascheme · Pull Request #142843 · python/cpython · GitHub

If we are specializing to LOAD_GLOBAL_MODULE or LOAD_ATTR_MODULE, try to enable deferred reference counting for the value, if the object is owned by a different thread.

Add a benchmark to ftscalingbench.py that shows the benefit of this change. The deepcopy benchmark uses globals like _local_atomic_types.

Issue: copy.copy and copy.deepcopy scale poorly with free-threading #132657

If we are specializing to LOAD_GLOBAL_MODULE, set deferred reference counting for the value, if it meets criteria. For now, it's only done for frozenset objects.

Use it for LOAD_ATTR_MODULE in addition to LOAD_GLOBAL_MODULE. Don't enable deferred ref counts if the object is owned by the current thread. Specialized bytecode is per-thread so this works. Enable for frozensets, tuples and type objects.

I think this makes sense and is worth doing. Let's also add a scaling test to ftscalingbench.py

Let's combine this lookup with the earlier _PyDict_LookupIndex. _PyDict_LookupIndex already gets the value internally and throws it away.

The !PyType_IS_GC and _PyObject_HasDeferredRefcount checks aren't really necessary because PyUnstable_Object_EnableDeferredRefcount handles those cases internally.

I think we should do this for all objects, not just a few types. Otherwise, I think we will keep run into scaling bottlenecks with global variables.

Hm... That's going to push a lot of objects to the GC for deallocation in programs that do a lot of work at the global level (but do have a few functions that are called enough that use those globals.) I'm thinking of naively written "scripts". Then again, it would only do that for objects that participate in GC (i.e. not strings or integers), so it's probably fine. I mean, nobody's too surprised when things aren't deallocated quite as quickly as they expect... right?

Yeah, I think this should be fine for main. I definitely wouldn't backport it to 3.14.

Definitely agree regarding not backporting to 3.14.

I think the above check that excludes owned by the current thread should help with most scripts -- it'll only affect global variables accessed by multiple threads.

Another thing that may help is that I think the PyUnstable_Object_EnableDeferredRefcount call only happens at specialization time, not every time a variable is updated or accessed.

Yeah, I'm a bit worried about increased memory usage. Since it's only for objects shared between threads and only for hot LOAD_GLOBAL/LOAD_ATTR instructions, maybe it's okay. Perhaps we should consider changing gc_should_collect() to check not only the young object count but also the process memory size increase as well. The condition with count < gcstate->long_lived_total / 4 could be done with an "or" condition with the process size check.

Also, avoid PyDict_GetItemRef() call by returning the value when the index is looked up (as previously discarded).

This is taken from the PR pythonGH-132658.

…erred

@nascheme There are merge conflicts.

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot ARM64 macOS 3.x (tier-2) has failed when building commit bb25f72.

What do you need to do:

Don't panic.
Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/725/builds/12575) and take a look at the build logs.
Check if the failure is related to this commit (bb25f72) or if it is a false positive.
If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/725/builds/12575

Failed tests:

test_urllib2net

Summary of the results of the build (if available):

==

Click to see traceback logs

remote: Enumerating objects: 17, done.        
remote: Counting objects:   6% (1/16)        
remote: Counting objects:  12% (2/16)        
remote: Counting objects:  18% (3/16)        
remote: Counting objects:  25% (4/16)        
remote: Counting objects:  31% (5/16)        
remote: Counting objects:  37% (6/16)        
remote: Counting objects:  43% (7/16)        
remote: Counting objects:  50% (8/16)        
remote: Counting objects:  56% (9/16)        
remote: Counting objects:  62% (10/16)        
remote: Counting objects:  68% (11/16)        
remote: Counting objects:  75% (12/16)        
remote: Counting objects:  81% (13/16)        
remote: Counting objects:  87% (14/16)        
remote: Counting objects:  93% (15/16)        
remote: Counting objects: 100% (16/16)        
remote: Counting objects: 100% (16/16), done.        
remote: Compressing objects:  33% (1/3)        
remote: Compressing objects:  66% (2/3)        
remote: Compressing objects: 100% (3/3)        
remote: Compressing objects: 100% (3/3), done.        
remote: Total 17 (delta 13), reused 13 (delta 13), pack-reused 1 (from 1)        
From https://github.com/python/cpython
 * branch                    main       -> FETCH_HEAD
Note: switching to 'bb25f7280af30831fffa3345b4fc93798949c6c6'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at bb25f7280af gh-132657: Add maybe_enable_deferred_ref_count() (gh-142843)
Switched to and reset branch 'main'

make: *** [buildbottest] Error 2

If we are specializing to `LOAD_GLOBAL_MODULE` or `LOAD_ATTR_MODULE`, try to enable deferred reference counting for the value, if the object is owned by a different thread. This applies to the free-threaded build only and should improve scaling of multi-threaded programs.

Add maybe_enable_deferred_ref_count().

8fae6ec

If we are specializing to LOAD_GLOBAL_MODULE, set deferred reference counting for the value, if it meets criteria. For now, it's only done for frozenset objects.

bedevere-app Bot mentioned this pull request Dec 16, 2025

copy.copy and copy.deepcopy scale poorly with free-threading #132657

Closed

colesbury requested review from Yhg1s, colesbury and mpage December 17, 2025 21:23

colesbury reviewed Dec 17, 2025

View reviewed changes

nascheme added 7 commits December 17, 2025 16:45

Enable deferred counting for more types.

03977d9

Also, avoid PyDict_GetItemRef() call by returning the value when the index is looked up (as previously discarded).

Add deepcopy benchmark to ftscalingbench.

5ef77af

This is taken from the PR pythonGH-132658.

Add comment for maybe_enable_deferred_ref_count().

04826f7

Merge remote-tracking branch 'origin/main' into specialize-enable-def…

1c59358

…erred

Add NEWS.

25192bd

Merge remote-tracking branch 'origin/main' into specialize-enable-def…

7888d1d

…erred

Don't use :opcode: markup.

9b9d01a

nascheme marked this pull request as ready for review December 29, 2025 16:58

nascheme requested review from markshannon and methane as code owners December 29, 2025 16:58

bedevere-app Bot added the awaiting core review label Dec 29, 2025

kumaraditya303 added performance Performance or resource usage topic-free-threading labels Jan 12, 2026

Merge 'origin/main' into specialize-enable-deferred

b0abdbd

kumaraditya303 approved these changes Jan 13, 2026

View reviewed changes

bedevere-app Bot added awaiting merge and removed awaiting core review labels Jan 13, 2026

Merge branch 'main' into specialize-enable-deferred

36d0710

nascheme enabled auto-merge (squash) January 17, 2026 01:40

nascheme merged commit bb25f72 into python:main Jan 17, 2026
47 checks passed

bedevere-app Bot removed the awaiting merge label Jan 17, 2026

kumaraditya303 mentioned this pull request Jan 19, 2026

threading primitives are subject to reference count contention #134761

Closed

nascheme mentioned this pull request Jan 19, 2026

Leak with untracked tuples and deferred ref counts #144054

Closed

eendebakpt mentioned this pull request Jan 20, 2026

gh-132657: Add free-threading scaling benchmark for copy.copy and copy.deepcopy #132658

Closed

ZeroIntensity mentioned this pull request Jan 21, 2026

gh-134761: Use deferred reference counting for threading concurrency primitives #134762

Closed

benediktjohannes mentioned this pull request Feb 16, 2026

gh-132657: Improve performance in specialize_dict_access_hint() via adding specialization for PY_GIL_DISABLED #144886

Open

+                  if (_Py_IsOwnedByCurrentThread(op) ||
+                          !PyType_IS_GC(Py_TYPE(op)) ||
+                          _PyObject_HasDeferredRefcount(op)) {
+                      Py_DECREF(op);
+                      return;
+                  }

gh-132657: Add maybe_enable_deferred_ref_count(). by nascheme · Pull Request #142843 · python/cpython · GitHub

Uh oh!

Uh oh!

gh-132657: Add maybe_enable_deferred_ref_count(). - #142843

gh-132657: Add maybe_enable_deferred_ref_count().#142843
nascheme merged 11 commits into
python:mainfrom
nascheme:specialize-enable-deferred

nascheme commented Dec 16, 2025 •
edited
Loading

Uh oh!

Uh oh!

colesbury left a comment

Uh oh!

colesbury Dec 17, 2025

Uh oh!

colesbury Dec 17, 2025

Uh oh!

colesbury Dec 17, 2025

Uh oh!

Yhg1s Dec 17, 2025

Uh oh!

colesbury Dec 17, 2025 •
edited
Loading

Uh oh!

Uh oh!

nascheme Dec 18, 2025

Uh oh!

kumaraditya303 commented Jan 12, 2026

Uh oh!

Uh oh!

bedevere-bot commented Jan 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

+                  PyObject *op;
+                  if (PyDict_GetItemRef(dict, name, &op) != 1) {
+                      return;
+                  }

+                  if (PyFrozenSet_Check(op) || PyTuple_Check(op) || PyType_Check(op)) {
+                      PyUnstable_Object_EnableDeferredRefcount(op);
+                  }

gh-132657: Add maybe_enable_deferred_ref_count(). by nascheme · Pull Request #142843 · python/cpython · GitHub

Uh oh!

Uh oh!

gh-132657: Add maybe_enable_deferred_ref_count(). - #142843

gh-132657: Add maybe_enable_deferred_ref_count().#142843nascheme merged 11 commits intopython:mainpython/cpython:mainfrom nascheme:specialize-enable-deferrednascheme/cpython:specialize-enable-deferredCopy head branch name to clipboard

Conversation

nascheme commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

colesbury left a comment

Choose a reason for hiding this comment

Uh oh!

colesbury Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

colesbury Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

colesbury Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Yhg1s Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

colesbury Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nascheme Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

kumaraditya303 commented Jan 12, 2026

Uh oh!

Uh oh!

bedevere-bot commented Jan 17, 2026

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

gh-132657: Add maybe_enable_deferred_ref_count().#142843
nascheme merged 11 commits into
python:mainfrom
nascheme:specialize-enable-deferred

nascheme commented Dec 16, 2025 •
edited
Loading

colesbury Dec 17, 2025 •
edited
Loading