Pointer comparisions are indeed not always well-defined. For reference: see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, section 6.5.8.6, or https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Pointer-Comparison.html.

I updated the PR to use the immortality bit instead.

(maybe there are some more places where we need to update documentation on the immortality bit)

Turns out the immortal bit was assumed to be zero in _PyLong_IsNonNegativeCompact. The updated _PyLong_IsNonNegativeCompact makes some of the operations with ints a (tiny) bit slower, so we have to measure performance a bit more carefull.

Turns out the immortal bit was assumed to be zero in _PyLong_IsNonNegativeCompact. The updated _PyLong_IsNonNegativeCompact makes some of the operations with ints a (tiny) bit slower, so we have to measure performance a bit more carefull.

@eduardo-elizondo already spotted that back then #102464 (comment) and created #103403, especially to target long_dealloc, see #103403 (comment).

@chris-eibl Thanks for that little bit of history.

@markshannon @eduardo-elizondo This PR is more or less identical to #103403 which has been closed. Unless you feel different about it now, I suggest we close this.

But your microbenchmarks for the initial version seemed promising.
Do you have numbers for the current version of the PR as well?

The results of the pyperformance fleet would be interesting, too, since you had to touch _PyLong_IsNonNegativeCompact.

I like that in your code the comment about Accidental De-Immortalizing is now exactly before _Py_SetImmortal.

In the previous version, I had to read carefully, especially because it starts with "This should never get called", which of course does not comment on the invocation of long_dealloc itself.

Every none-small-int will be deallocated, and for all of them we pay the price of _PyLong_IsCompact. If it is a compact int (very likely), then a bunch more code is executed. Especially for small int values we have to check whether they match the singletons to care about accidential de-immortaliziation. And we have to go down to the if (pylong == small_pylong) for all small int values for everything that derives from int.

I don't care much about IntEnums or their "predecessors" class _NamedIntConstant(int) , etc, since those most likely aren't deallocated before the end of the programm. But e.g. extensions that derive from int.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@markshannon Adding the small int check for the free-threaded build uncovered a bug: we have to prevent copying the immortal bit when subclassing int. I addresed the bug in long_subtype_new and added an assert to _long_is_small_int to detect similar issues.

I have made the requested changes; please review again

Thanks for making the requested changes!

@markshannon: please review the changes made to this pull request.