python / python/cpython

Deferred reference counts

未關閉
#120,024 1 則留言 2 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

interpreter-core performance type-feature
主要語言
Python
星號
77.2k
分支
36k
PR 合併指標
PR 指標待擷取

描述

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

https://github.com/faster-cpython/ideas/issues/677

Linked PRs
  • gh-121917
  • gh-121923
  • gh-122693
  • gh-122730
  • gh-122734
  • gh-122780
  • gh-122968
  • gh-125095
  • gh-125192
### Tasks
- [ ] https://github.com/python/cpython/issues/123391
- [x] Interpreter code generators need to be able to flush the stack around escaping calls.

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

首先查看連結的 PRs 以及 faster-cpython/ideas#677 中先前的討論,然後檢查 issue #123391 中剩餘的工作。此提案涵蓋延遲參照計數、零計數追蹤和回收時機;要完成這項工作,需要解決列出的實作問題並完成尚未完成的工作。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
python
領域
compilers
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
停滯
描述清晰度
需要釐清
新手友好度
15/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。