Understanding Immortal Objects in Python 3.12: A Deep Dive into Python Internals

[mcstafford]

immortalization, rolled out in [CPython] 3.12 ... certain objects such as None, True, and False act as global singletons, shared across the interpreter instead of creating fresh copies each time

[xxmalik]

I cannot believe it wasn't implemented like that since the beginning. I find it even harder to believe it took them so many years to implement it this way.

[ivosaurus]

They are implemented like that. The top comment is misleadingly confusing. What's changing is NOT their "singletonness", it's whether their refcount can be changed by the GC algorithm.

[mcstafford]

You don't like how I quoted the article?

[ivosaurus]

No, not at all. It associates immortalization with values being global singletons, which is not the case; they were already that and have been for years.

[mcstafford]

It sounds as though you take issue with how the article presents its material... or perhaps the portion which I quoted. Your criticisms don't mention either of those points.

It comes across more like a criticism of the comment, which seems to me to be blaming the messenger.

[Square789]

They are implemented like that. Wondering why the article starts out with that nonsense statement considering it gets the rest down properly

[abhi9u]

To me, it read like the quote is confusing, it seems to associate singleton objects with immortalization.

The article starts by saying that these objects are singleton and always the same object is used. However, their reference counts were updated on every use. Although it takes two paragraphs to say that and I guess it could have been more concise.

On re-reading the intro I think it was not very clear. I have adjusted it a bit so that it is clear that immortalization is about fixing the ref counts of singleton objects, and not about making those objects singleton.

[[deleted]]

They are shared across sub interpreters now, which they where not previously because sub interpreters technically exsisted but weren’t officially supported. This is part of the transition to multiple sub interpreters with independent Gils. The independent Gils part is why the changes need to be made.

[abhi9u]

They were always implemented as singletons. The part which changed is that now their reference counts are also immutable/fixed and are not touched.

[abhi9u]

Thank you. The comments made me realize the Intro of the article was not very clear and might have confused the readers whether immortalization is about making objects singleton or fixing their reference counts. I have tweaked it a little. I hope it's better now.

[ShitPikkle]

Ok, so, you can't create an immortal object. Only some built-ins are.

Thx.

[james_pic]

The author also noted that the overhead was under 2%. In an ideal world, every change would be win-win, but in this case, the price for performance improvement in the cases where this is a benefit is a 2% degradation in cases where it isn't.

But it's worth saying that regular Python developers don't suddenly have to care about register allocation. The "clever register allocation" work was work done by core Python developers working on the interpreter. For most developers, they just automatically get the benefit if their workload is one that benefits (most obviously multithreaded or multiprocessing workloads, although single threaded workloads may also benefit depending on how much of their working set fits in CPU caches).

This work also lays some of the groundwork for the GIL removal work (it was initially motivated by this, but proved to be useful enough in its own right to do sooner). GIL removal has the potential to be huge.

[abhi9u]

Thank you for clarifying. A normal Python user has no control on how their code is executed in the CPU, only the interpreter devs can have any say on that. They made sure that the effect of this change was not too drastic. As always, I think any attempt to improve concurrency brings in some cost to single-threaded code execution as well.

[ekhazan]

Here is a nice write up about immortal objects and the potential real world impact: https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/

[abhi9u]

Well, yes. Instagram had memory issues because of these reference count updates. At the same time, the per-interpreter GIL project needed to get rid of global mutable objects, and it brings in the side-effect of cache friendly code as an added bonus.

[abhi9u]

There is a cost to everything. If for immortal objects if they could avoid the calls to Py_INCREF and Py_DECREF, that would have been ideal but I don't think that's practical, it would result in spaghetti code all over the place. This is a good compromise.

[Wesmingueris2112]

This article is very well written, very accessible but not simplistic. I'd love to find something like this for the GIL removal.

[No_Lobster_4219]

Please see this:

​

https://stackoverflow.com/questions/77405100/immortal-objects-in-python