Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deferred reference counts #120024

Open
markshannon opened this issue Jun 4, 2024 · 1 comment
Open

Deferred reference counts #120024

markshannon opened this issue Jun 4, 2024 · 1 comment
Labels
3.14 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage type-feature A feature request or enhancement

Comments

@markshannon
Copy link
Member

markshannon commented Jun 4, 2024

Feature or enhancement

Proposal:

Approximately 80% of reference count operations occur in the interpreter. stats
The vast majority of these operations are needed only to maintain the correct reference counts for references in local variables and the evaluation stack.
We should not count these references, instead deferring them until we wish to perform incremental collection.

Doing so will give us a reasonable speedup on default builds, but the real value is for free-threading.
Free-threading requires that some references on the frame stack are deferred, but tagging those references is expensive. It is much more efficient to simply deferred all references on the frame stack.

This is not a new idea, in fact it is a very old one.

The implementation is conceptually fairly simple:

  • We don't count references in local variables and the evaluation stack
  • Any object that has a reference count of zero is, instead of being reclaimed, added to a "Zero count table"
  • When we perform collection, we update the reference count of all objects that have references on the stack, collect any objects with a zero reference count, and then reset the reference counts.

Like many "simple" ideas, the devil is in the detail.

There are two main concerns:

  • Reclamation of objects is not as prompt as before. We may use more resources, waiting for them to be reclaimed.
  • The overhead of updating references during collections may be as great or greater than the saving by deferring the reference counting.

We can keep reclamation acceptably prompt, by tracking the size of objects in the Zero Count Table, the size of objects allocated.
Once this number gets large enough, we perform a collection at the next opportunity.

We can keep the overhead of updating the reference counts low, by only deferring the top of the stack. Parts of the stack that are not accessed between collections, can be counted eagerly, reducing the amount of scanning needed to a few frames.

Previous discussion

faster-cpython/ideas#677

@markshannon markshannon added type-feature A feature request or enhancement performance Performance or resource usage labels Jun 4, 2024
@markshannon
Copy link
Member Author

#119866 shows that it is possible to keep all stack pointers reachable in memory whenever execution escapes from the interpreter. This means that we make reclamation as prompt as want.

@markshannon markshannon added 3.14 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage type-feature A feature request or enhancement
1 participant