Pablo Galindo Salgado <pablog...@gmail.com> added the comment:
> I think this is simply expected behavior if you choose to create immortal > objects, and not really an issue. How could you have an immortal object that > doesn't keep its strong references alive? I think I didn't express myself very well: I am saying that I perceive this as a problem because when you immortalize the heap at a given time you will also immortalize any strong reference that these objects made afterwards. The immortal property will be "infecting" other objects as strong references are created. > I think the last sentence here is not quite right. An immortalized object > will never start participating in reference counting again after it is > immortalized. Yeah, but the objects I mention will not be immortalized. These are objects that were not tracked when the immortalization is done and are not reachable from tracked objects at the moment and become tracked afterwards (for instance, some dictionary that only had immutable objects when the immortalization was done). And this is always very impacting: a single object that participates in refcounting will copy an entire page of memory. Although I agree this is a rare thing is a possible thing that can happen. > I think the word "corrupted" makes this sound worse than it is in practice. > What happens is just that the object is still effectively immortal (because > the immortal bit is a very high bit), but the copy-on-write benefit is lost > for the objects touched by old extensions. Yeah, I agree that corrupted may sound a bit more dramatic than it should but I think this is still a problem because when it happens (as mentioned before) it affects entire pages and not the single object that we consider. > But for the "not GC tracked but later becomes GC tracked" case, it will not > re-enter reference counting, only the GC. But if said objects (isolated and untracked before and now tracked) acquire strong references to immortal objects, those objects will be visited when the gc starts calculating the isolated cycles and that requires a balanced reference count to work. ---------- nosy: -dino.viehland _______________________________________ 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
