[issue39061] Garbage Collection optimizations cause "memory leak"

Pablo Galindo Salgado report at bugs.python.org
Mon Dec 16 08:30:56 EST 2019


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> It happens to cause huge memory leaks if the self-referencing objects occupies a lot of RAM, which should be expected.

The fact that the GC will take longer time does not qualify this as memory leaks. A memory leak is by definition memory that cannot be reclaimed and in this case, once the collection of the old generation happens it will be collected, therefore is not a "leak" per se.

> I think the best and simplest solution would be to move the objects one generation at a time. This would avoid the heavy but short-lived objects to make it to the old generation.

This has also other downsides, like objects that won't be collected will suffer more traversals and collections, that can be impactful in performance, so is not that simple. 

I am currently working on an experiment to see if we can detect "nepotism" (check https://www.memorymanagement.org/glossary/n.html for a definition) and this will likely help with your problem.

In the meanwhile, I think the most portable option is forcing collections yourself or adjusting the gc parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________


More information about the Python-bugs-list mailing list