Skip to content

PEP 683: Fix broken links #5233

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.

Sign up for GitHub

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

Merged
StanFromIreland merged 1 commit into from
Nov 12, 2026
Merged

PEP 683: Fix broken links #5233

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions peps/pep-0683.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ PEP Acceptance Conditions

The PEP was accepted with conditions:

* the primary proposal in `Solutions for Accidental De-Immortalization`_
* the primary proposal in :ref:`pep683-solutions`
(reset the immortal refcount in ``tp_dealloc()``) was applied
* types without this were not immortalized (in CPython's code)
* the PEP was updated with final benchmark results once
Expand Down Expand Up @@ -219,7 +219,7 @@ types, as well as objects exposed by the public C-API.

In general, a strong immutability guarantee for objects enables Python
applications to scale better, particularly in
`multi-process deployments <Facebook>`_. This is because they can then
`multi-process deployments <Facebook_>`_. This is because they can then
leverage multi-core parallelism without such a significant tradeoff in
memory usage as they now have. The cases we just described, as well as
those described above in `Motivation`_, reflect this improvement.
Expand All @@ -234,7 +234,7 @@ of basic mitigations applied. See the `mitigations`_ section below.
.. _a 2% slowdown: https://github.com/python/cpython/pull/19474#issuecomment-1502245844

On the positive side, immortal objects save a significant amount of
memory when used `with a pre-fork model <Facebook>`_. Also, immortal
memory when used `with a pre-fork model <Facebook_>`_. Also, immortal
objects provide opportunities for specialization in the eval loop that
would improve performance.

Expand Down Expand Up @@ -395,7 +395,7 @@ mitigation is simple enough that we can safely proceed under the
assumption that it would not be a problem.

We look at possible solutions
`later on <Solutions for Accidental De-Immortalization>`_.
:ref:`later on <pep683-solutions>`.

Alternate Python Implementations
--------------------------------
Expand Down Expand Up @@ -709,6 +709,8 @@ other possibilities
* (Larry,MAL) allocate (immutable) immortal objects in their own memory page(s)
* saturated refcounts using the 32 least-significant bits

.. _pep683-solutions:

Solutions for Accidental De-Immortalization
-------------------------------------------

Expand Down Expand Up @@ -839,8 +841,8 @@ Here is the internal state that the CPython runtime keeps
for each Python object:

* `PyObject.ob_refcnt`_: the object's `refcount <refcounting_>`_
* `_PyGC_Head <PyGC_Head>`_: (optional) the object's node in a list of `"GC" objects <refcounting_>`_
* `_PyObject_HEAD_EXTRA <PyObject_HEAD_EXTRA>`_: (optional) the object's node in the list of heap objects
* `_PyGC_Head <PyGC_Head_>`_: (optional) the object's node in a list of `"GC" objects <refcounting_>`_
* `_PyObject_HEAD_EXTRA <PyObject_HEAD_EXTRA_>`_: (optional) the object's node in the list of heap objects

``ob_refcnt`` is part of the memory allocated for every object.
However, ``_PyObject_HEAD_EXTRA`` is allocated only if CPython was built
Expand Down
Loading