Pablo Galindo Salgado <pablog...@gmail.com> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40255> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
