[issue39143] Implementing sub-generation steps in the gc

Tim Peters report at bugs.python.org
Sat Dec 28 14:53:07 EST 2019


Tim Peters <tim at python.org> added the comment:

Long ago I thought about adding "a buffer in front of" CPython's cyclic gc:  newly tracked items would be added there, and not participate in cyclic gc at all until a collection passed.

For example, break the youngest generation into parts A & B.  Newly tracked items are added to part A.  When a collection occurs, only part B participates from the youngest generation.  When the collection ends, part A is renamed to part B, and part A is marked empty (just a handful of pointer manipulations).

Seems a similar thrust, but a more extreme goal:  trying to maximize the number of new containers that can be reclaimed by refcounting alone without _ever_ being chased by cyclic gc.

Beyond that most objects "die young", which appears overwhelmingly truer than not across almost all Python programs, I'm not sure anything else about lifetime distribution is generally exploitable.

About "5 bits", no, we don't have 'em.  Even the relatively modest ugliness we have now makes it impossible to port Python to a word-addressed machine (I'm not sure any still exist!).  Nothing in C guarantees the last 2 or 3 bits of a pointer "are 0".  We're already using two words to store 2 persistent pointers, one persistent flag, a full-width transient reference count, and two transient flags.

----------

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


More information about the Python-bugs-list mailing list