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 mistasse
Recipients mistasse
Date 2019-12-16.10:01:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
In-reply-to
Content
When working on a self-referencing object in the young generation and the middle-generation collection kicks in, that object is directly moved to the old generation. (if I understood this well: https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1192)
Then, it won't be freed until the old generation is collected, which happens to be much later. (because of this: https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1388)

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

This is of course the kind of problem that I expect with garbage collection with bad parameters.

However, I also expected that playing with threshold0 could have been sufficient to solve it. However, the fact that we move the object to old generation every time the middle collection pops in forces the problem to happen once in a while, and in the end reaching very high memory consumption.

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.
History
Date User Action Args
2019-12-16 10:01:35mistassesetrecipients: + mistasse
2019-12-16 10:01:34mistassesetmessageid: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
2019-12-16 10:01:34mistasselinkissue39061 messages
2019-12-16 10:01:34mistassecreate