Some minor edits.

Author: ZeroIntensity

peps/pep-0797.rst

@@ -76,19 +76,20 @@ the magic immortal number. But again, this isn't totally safe; for example, due
 to the current string interning implementation, immortalizing a string can cause
 crashes. To make matters worse, there's no mechanism in place to deallocate an
 object once it has become immortal; this is limiting for potential optimizations
-using immortality.
+using immortality, because immortal objects stored on the heap (and the memory
+that they own) are leaked.
 
 What Problem Does Immortality Solve?
 ************************************
 
 Currently, the main way to share objects between subinterpreters is via
 serialization. This works OK, but can be limited for many objects.
-Immortality is a good precursor to directly sharing objects across multiple
+Immortality is a necessary precursor to directly sharing objects across multiple
 interpreters, as it provides a way to make reference counting thread-safe
 without atomic operations on the reference count field (which has proven to
 drastically hurt performance).
 
-Subinterpreters aside, immortality is just generally a powerful tool to wield,
+Subinterpreters aside, immortality is just generally a powerful tool,
 especially for CPython maintainers. The authors of this PEP do not expect that
 immortality will become a common tool for Python code, but the complexity of
 the approach on its own warrants a PEP.
@@ -100,10 +101,12 @@ other areas of CPython, or in third-party libraries:
   build are still subject to reference count contention. It is possible to help
   mitigate this problem through deferred reference counting in the C API
   (:c:func:`PyUnstable_Object_EnableDeferredRefcount`), but that has the downside
-  of damaging single-threaded performance.
+  of damaging single-threaded performance. Immortality is able to avoid reference
+  count contention while also keeping good single-threaded performance.
 - Immortality can help memory usage by avoiding copy-on-write operations in
   child processes. Instagram has been `doing this in Cinder`_ for years,
-  and it would be nice to let CPython also take advantage of it.
+  and it would be nice to let CPython also take advantage of it. This is
+  mainly an incidental goal of this PEP.
 
 .. _doing this in Cinder: https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/
 
@@ -113,10 +116,10 @@ Immortal Objects Must Remain in CPython
 
 In the past, the main pushback to exposing APIs for immortality is that
 it's exposing an implementation detail, and would force CPython to keep
-immortality forever. Unfortunately, we've already reached that point: too
-many users, and `CPython itself`_, omit reference counting for known immortal
-objects, such as :c:data:`Py_None`. Since there's no good way to deprecate
-that, CPython will always need some form of immortality to retain
+immortality forever. Unfortunately, it's likely that point has already been
+reached: too many users, and `CPython itself`_, omit reference counting for
+known immortal objects, such as :c:data:`Py_None`. Since there's no good way
+to deprecate that, CPython will always need some form of immortality to retain
 compatibility. That said, this proposal still keeps all new APIs unstable.
 
 .. _CPython itself: https://github.com/python/cpython/issues/103906
@@ -132,8 +135,9 @@ which will be discussed further in a moment. As of writing, the rule
 is that you cannot modify the reference count of an object created
 in a different interpreter, and since you can't modify the reference
 count, you can't do anything with the object. Since immortality prevents
-reference counting operations, this PEP hopes to solve that issue, allowing
-for an object proxy that can safely be reference counted in all interpreters.
+reference counting operations, this PEP will solve that issue, allowing
+for an object proxy that can safely be used with reference counting APIs
+in all interpreters.
 
 Reference Count Modifications Must be Per-interpreter
 -----------------------------------------------------
@@ -143,7 +147,7 @@ by the interpreter's GIL, meaning that trying to modify the reference count of
 an object that belongs to another interpreter could cause data races.
 
 This isn't a problem on the free-threaded build as reference count operations
-are atomic, but subinterpreters are supported on the with-GIL build. An
+are atomic, but subinterpreters are supported on the GIL-enabled build. An
 alternative option could be to make reference counting also atomic on the
 GIL-enabled build, but that has been shown to damage single-threaded performance
 or compromise compatibility with the stable ABI.
@@ -169,6 +173,16 @@ In doing so, an object will release its memory back to CPython's object allocato
 allocator is per-interpreter, so it is unsafe to try to release an object's
 memory in an interpreter different from the one that created it.
 
+Immortality Has No Impact on Reference Counting Performance
+-----------------------------------------------------------
+
+If the primary issue with cross-interpreter reference counting is thread-safety,
+why not make reference counting atomic? Unfortunately, atomic operations are
+slower than their non-atomic counterparts, so this would hurt overalll
+performance. :pep:`703` managed to solve this issue using biased reference
+counting, splitting the reference count field into two, but at the cost of
+breaking the stable C API. Atomic reference counting on its own also doesn't
+solve the per-interpreter deallocator issue as mentioned previously.
 
 Immortality is a Powerful Tool to Wield
 ***************************************
@@ -604,7 +618,7 @@ Backwards Compatibility
 The `Immortalization Contract`_ is very slightly backwards-incompatible.
 The contract is based on best practices in the C API; it doesn't have
 anything that's really new, it's just based around what objects currently
-do. That being said, there was nothing enforcing before that objects follow
+do. That being said, there was nothing previously enforcing that objects follow
 these assumptions, but the authors of this PEP have never seen code in the
 wild that breaks the immortalization contract.