This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pablogsal
Recipients corona10, eelizondo, gregory.p.smith, nascheme, pablogsal, pitrou, steve.dower, tim.peters
Date 2020-04-13.20:06:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thanks, Eddie for sharing the patch. I think this is an interesting discussion: for instance, in the core dev sprint at Microsoft I recall that we had a quick discussion about having immortal references. 

After analyzing the patch, and even assuming that we add conditional compilation, here are some of the things I feel uneasy about:

- Anything that is touched by the immortal object will be leaked. This can also happen in obscure ways
  if reference cycles are created.

- As Eddie mentions in the PR, this does not fully cover all cases as objects that become tracked by the GC
  after they are modified (for instance, dicts and tuples that only contain immutable objects). Those objects will
  still, participate in reference counting after they start to be tracked.

- As Gregory mentions, if immortal objects are handed to extension modules compiled with the other version of the
  macros, the reference count can be corrupted. This may break the garbage collector algorithm that relies on the
  the balance between strong references between objects and its reference count to do the calculation of the isolated cycles.
  This without mentioning that this defies the purpose of the patch in those cases, as a single modification of the reference 
  the count will trigger the copy of the whole memory page where the object lives.

- The patch modifies very core mechanics of Python for the benefit of a restricted set of users (as Gregory mentions): no 
  threads, POSIX and forking.

- Is not clear to me that leaking memory is the best way to solve this problem compared to other solutions (like having the 
  the reference count of the objects separated from them).
  objects separated from them.

There is a trend right now to try to remove immortal objects (started by Victor and others) like static types and transforming them to heap types. I am afraid that having the restriction that the interpreter and the gc needs to be aware
of immortal types can raise considerably the maintenance costs of already complicated pieces of the CPython VM.
Date User Action Args
2020-04-13 20:06:53pablogsalsetrecipients: + pablogsal, tim.peters, nascheme, gregory.p.smith, pitrou, steve.dower, corona10, eelizondo
2020-04-13 20:06:53pablogsalsetmessageid: <>
2020-04-13 20:06:53pablogsallinkissue40255 messages
2020-04-13 20:06:52pablogsalcreate