[issue31558] gc.freeze() - an API to mark objects as uncollectable

[Neil Schemenauer]

Neil Schemenauer added the comment:

I think the basic idea makes a lot of sense, i.e. have a generation that is never collected.  An alternative way to implement it would be to have an extra generation, e.g. rather than just 0, 1, 2 also have generation 3.  The collection would by default never collect generation 3.  Generation 4 would be equivalent to the frozen generation.  You could still force collection by calling gc.collect(3).  Whether that generation should be collected on shutdown would still be a question.

If this gets implemented, it will impact the memory bitmap based GC idea I have been prototyping.  Currently I am thinking of using two bits for each small GC object.  The bits would mean: 00 - untracked, 01 - gen 0, 10 - gen 1, 11 - gen 2.  With the introduction of a frozen generation, I would have to use another bit I think.

Another thought is maybe we don't actually need 3 generations as they are currently used.  We could have gen 0 which is collected frequently and gen 1 that is collected rarely.  The frozen objects could go into gen 2 which are not automatically collected or have a user adjustable collection frequency.  Collection of gen 1 would not automatically move objects into gen 2.

I think issue 3110 (https://bugs.python.org/issue31105) is also related.  The current GC thresholds are not very good.  I've look at what Go does and the GC collection is based on a relative increase in memory usage.  Python could do perhaps something similar.  The accounting of actual bytes allocated and deallocated is tricky because the *_Del/Free functions don't actually know how much memory is being freed, at least not in a simple way.

----------

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