I'd like to add here that while these objects will never be cleaned up during the runtime, except, when the runtime knows it's safe to do safe. For example, at runtime shutdown when we clean and deallocate all strings.

Option 1:
and thus the object will never be cleaned up, unless explicitly deallocated by the runtime.

Option 2:
and thus the object will never be cleaned up, unless explicitly deallocated by the runtime when it knows it's safe to do so.

What do you think?

Not sure if the specific number matters too much but this 4% was measured in a pretty old branch. When I remeasured this with a branch from April 2022 for PyCon, it was at ~6% for the naive implementation.

I noticed on reddit, btw, that some people who read my Language Summit article were also slightly confused about whether immortal objects would make things faster or slower :) https://www.reddit.com/r/Python/comments/unx80h/comment/i8c2q7p/

The UI doesn't let me add a comment where I want it but in the paragraph above, it says:

However, we do ensure that immortal objects (mostly) stay immortal
in that situation.  We set the initial refcount of immortal objects to
a value high above the magic refcount value, but one that still matches
the high bit.

This might be too specific on the implementation details (i.e assuming it's using a high bit). Under the new lower 32 bit strategy (which we use for better perf) these assumptions might change.

Maybe let's just drop the last sense that says: "but one that still matches the high bit"?

In the Maintainability section below, it says:

However, that should be limited to where we immortalize all
objects post-init and that code will be in one place.

What about extending that to say:

However, that should be limited to where we immortalize all
objects post-init and explicitly deallocate them at runtime shutdown.

As I've investigated in some of the mitigation strategy, it might be hard to guarantee that the code that immortalizes all objects will be in one single place. For instance, interned strings are immortalized when they are created inside the unicode C-API functions.

Also, wanted explicitly call out that these are deallocating immortal objects at shutdown

In the specification above, the second bullet point, maybe let's remove the part that says: '(or its most significant bit)', I think the sentence before that is specific enough and this parenthesis dives into implementation details

Looks solid! Thanks for expanding this!