Pointer comparisions are indeed not always well-defined. For reference: seehttps://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, section 6.5.8.6, orhttps://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 targetlong_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 thepyperformance 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 oflong_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 theif (pylong == small_pylong) for all small int values for everything that derives fromint.

I don't care much aboutIntEnums 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 fromint.

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 phraseI 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 inlong_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.