Author nascheme
Recipients barry, benjamin.peterson, davin, inada.naoki, lukasz.langa, nascheme, pitrou, rhettinger, tim.peters, vstinner, yselivanov
Date 2017-09-25.18:55:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506365751.51.0.196053174056.issue31558@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-09-25 18:55:51naschemesetrecipients: + nascheme, tim.peters, barry, rhettinger, pitrou, vstinner, benjamin.peterson, inada.naoki, lukasz.langa, yselivanov, davin
2017-09-25 18:55:51naschemesetmessageid: <1506365751.51.0.196053174056.issue31558@psf.upfronthosting.co.za>
2017-09-25 18:55:51naschemelinkissue31558 messages
2017-09-25 18:55:51naschemecreate