Expand the abstract.

python · ericsnowcurrently · Mar 1, 2022 · Feb 26, 2022 · Feb 26, 2022 · Feb 26, 2022
commit 6771a73b146ae151e1bd04dd6cb5fc03951b714b
@@ -19,29 +19,65 @@ Currently the CPython runtime maintains a
 allocated memory of each object.  Because of this, otherwise immutable
 objects are actually mutable.  This can have a large negative impact
 on CPU and memory performance, especially for approaches to increasing
-Python's scalability.  The solution proposed here provides a way
-to mark an object as one for which that per-object
-runtime state should not change.
-
-Specifically, if an object's refcount matches a very specific value
-(defined below) then that object is treated as "immortal".  If an object
-is immortal then its refcount will never be modified by ``Py_INCREF()``,
-etc.  Consequently, the refcount will never reach 0, so that object will
-never be cleaned up (unless explicitly done, e.g. during runtime
-finalization).  Additionally, all other per-object runtime state
-for an immortal object will be considered immutable.
-
-This approach has some possible negative impact, which is explained
-below, along with mitigations.  A critical requirement for this change
-is that the performance regression be no more than 2-3%.  Anything worse
-than performance-neutral requires that the other benefits are proportionally
-large.  Aside from specific applications, the fundamental improvement
-here is that now an object can be truly immutable.
-
-(This proposal is meant to be CPython-specific and to affect only
-internal implementation details.  There are some slight exceptions
-to that which are explained below.  See `Backward Compatibility`_,
-`Public Refcount Details`_, and `scope`_.)
+Python's scalability.
+
+This proposal mandates that, internally, CPython will support marking
+an object as one for which that runtime state will no longer change.
+Consequently, such an object's refcount will never reach 0, and so the
+object will never be cleaned up.  We call these objects "immortal".
+(Normally, only a relatively small number of internal objects
+will ever be immortal.)
+
+The fundamental improvement here is that now an object
+can be truly immutable.
+
+Scope
+-----
+
+Object immortality is meant to be an internal-only feature.
+So this proposal does not include any changes to public API or behavior.
+However, this does not prevent us from adding (publicly accessible)
+private API to do things like immortalize an object or tell if one
+is immortal.
+
+Any effort to expose this feature to users would need to be proposed
+separately.  There is one exception: refcounting semantics for immortal
+objects will differ in some cases from user expectations.  This
+exception, and the solution, are discussed below.
+
+Most of this PEP focuses on an internal implementation that satisfies
+the above mandate.  However, those implementation details are not meant
+to be strictly proscriptive.  Instead, at the least they are included
+to help illustrate the technical considerations required by the mandate.
+The actual implementation may deviate somewhat.  Furthermore, the
+acceptability of any implementation detail described below does not
+depend on the status of this PEP, unless explicitly.specified.
+
+For example, the particular details of:
+
+* how to mark something as immortal
+* how to recognize something as immortal
+* which subset of functionally immortal objects are marked as immortal
+* which memory-management activities are skipped or modified for immortal objects
+
+are not only CPython-specific but are also private implementation
+details that are expected to change in subsequent versions.
+
+Implementation Summary
+----------------------
+
+Here's a high-level look at the implementation:
+
+If an object's refcount matches a very specific value (defined below)
+then that object is treated as immortal.  The CPython C-API and runtime
+will not modify the refcount (or other runtime state) of an immortal
 object.
+
+Aside from the change to refcounting semantics, there is one other
+possible negative impact to consider.  A naive implementation of the
+approach described below makes CPython roughly 4% slower.  However,
+the implementation is performance-neutral once known mitigations
+are applied.
 
 
 Motivation