"immortal" objects

[ericsnowcurrently]

The idea of "immortal" objects is basically that we can skip certain operations if we know that an object will never go away. That includes objects like the singletons, small ints, and static types. There are several potential benefits to immortal objects:

• allows immutable objects to be shared directly between interpreters (my favorite)
• allows better copy-on-write behavior when forking
• optimizations

(related: tagged pointers)

Prior Art

Eddie Elizondo PR (April 2020)

Early last year, Eddie Elizondo posted a PR for supporting "immortal" objects, with a focus on the interests of his team at Facebook. See:

• gh-84436: Implement Immortal Objects python/cpython#19474
• https://bugs.python.org/issue40255

The key changes there are in Include/object.h and Objects/object.c. Eddie's main motivation is to facilitate better copy-on-write behavior when forking. I think he showed some promising results but there were concerns about the costs under general Python usage.

Eric's Branch (December 2020)

In December I started working on the problem Python objects that are exposed via the public API (and even stable API), relative to subinterpreters not sharing the GIL. I tried out two solutions.

The first was actually very similar to Eddie's, which I didn't know about until a week or two later. Once I found Eddie's PR I made a few tweaks to my branch. See: ericsnowcurrently/cpython#9. My change should have basically no negative performance impact.

The other approach I tried was sticking a dummy object into ob_type. However, I confident that there are problems there not worth resolving. See: python/cpython@master...ericsnowcurrently:globals-immortal-objects-obtype.

[ericsnowcurrently]

I've created a PR for my branch: python/cpython#24828

[ericsnowcurrently]

FYI, I've created https://bugs.python.org/issue43503 to address the motivating problem directly.

[markshannon]

Instagram have shown that immortal objects actually slow things down. They consider it worth it because of the memory saving across multiple interpreters with their compile-everything-then-fork model

We have no plans to support a late fork model, or anything like it. So I'd like to close this issue.

[gvanrossum]

I'd wait for @ericsnowcurrently to comment -- he has a different implementation that doesn't slow things down (because the INCREF/DECREF macros aren't affected -- you just have leniency in not using those if you know you have an immortal object, e.g. None).

[ericsnowcurrently]

Right. See the description in my original message here.

Instagram modified Py_INCREF and Py_DECREF to keep the refcount of immortal objects from changing (to avoid copy-on-write after forking). Hence the performance hit they reported, which they say was more than offset by savings (for their case) elsewhere due to unchanging refcounts.

My branch has virtually no negative performance impact because it does not add that penalty to Py_INCREF and Py_DECREF.

That said, I already marked this as "abandoned". For now I don't see much value here to our performance efforts, so I'm closing the issue (on this tracker). I may still follow this through on my own for other reasons though. 🙂

[ericsnowcurrently]

FYI, I just saw that if you close an issue, it is not removed from the GitHub project it is in. It just gets moved to the "Done" lane. Other than having to move it back to the "Abandoned" lane, this worked the way I had hoped it would.