Deferred reference counts
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- 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.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、リンクされたPRsと faster-cpython/ideas#677 の以前の議論を確認し、次に issue #123391 に残っているタスクを調査します。この提案は、遅延参照カウント、ゼロカウントの追跡、コレクションのタイミングを対象としており、完了するには、列挙された実装上の懸念を解決し、未完了のタスクを完了する必要があります。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- compilers
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 15/100