[New-bugs-announce] [issue39061] Garbage Collection optimizations cause "memory leak"

[Maxime Istasse]

New submission from Maxime Istasse <istassem at gmail.com>:

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.

----------
components: Interpreter Core
files: late_gc.py
messages: 358469
nosy: mistasse
priority: normal
severity: normal
status: open
title: Garbage Collection optimizations cause "memory leak"
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48780/late_gc.py

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