-
-
Notifications
You must be signed in to change notification settings - Fork 33.6k
gh-124379: Document _PyStackRef #142321
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
base: main
Are you sure you want to change the base?
gh-124379: Document _PyStackRef #142321
Conversation
Fidget-Spinner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM. Could you also please take a look at #141675 ? If that goes in, then some of the docs will go out of date as we won't be using different tagging schemes anymore.
mpage
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just some suggestions inline
| Going back to `PyObject*` mirrors this: | ||
|
|
||
| - `PyStackRef_AsPyObjectBorrow(ref)` - borrow the underlying pointer | ||
| - `PyStackRef_AsPyObjectSteal(ref)` - transfer ownership from the stackref |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If ref is borrowed/deferred this will create a new owning reference. Not sure it's worth documenting, but I figured I'd call it out since this is not exactly the dual of PyStackRef_FromPyObjectSteal.
| Objects that support deferred reference counting can be pushed to the evaluation | ||
| stack and stored in local variables without directly incrementing the reference | ||
| count because they are only freed during cyclic garbage collection. This avoids | ||
| reference count contention on short-lived values such as methods and types. The GC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing to me because methods and types tend to be long-lived.
| reference count contention on short-lived values such as methods and types. The GC | |
| reference count contention on commonly shared objects such as methods and types. The GC |
|
|
||
| In GIL builds, most objects carry their refcount; tagged borrowed refs skip decref on close. In free | ||
| threading builds, the tag is also used to mark deferred refcounted objects so the GC can see them and | ||
| to avoid refcount contention for short-lived stack values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably misreading this as it's written (it's Friday afternoon) but the following is clearer to me
| to avoid refcount contention for short-lived stack values. | |
| to avoid refcount contention on commonly shared objects. |
| - `Py_TAG_REFCNT` clear - reference count lives on the pointed-to object. | ||
| - `Py_TAG_REFCNT` set - ownership is "borrowed" (no refcount to drop on close) or the object is immortal. | ||
| - `Py_INT_TAG` - tagged small integer stored directly in the stackref (no heap allocation). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - `Py_TAG_REFCNT` clear - reference count lives on the pointed-to object. | |
| - `Py_TAG_REFCNT` set - ownership is "borrowed" (no refcount to drop on close) or the object is immortal. | |
| - `Py_INT_TAG` - tagged small integer stored directly in the stackref (no heap allocation). | |
| - `Py_TAG_REFCNT` unset - reference count lives on the pointed-to object. | |
| - `Py_TAG_REFCNT` set - ownership is "borrowed" (no refcount to drop on close) or the object is immortal. | |
| - `Py_INT_TAG` set - tagged small integer stored directly in the stackref (no heap allocation). |
Uh oh!
There was an error while loading. Please reload this page.