[Neil Schemenauer] > ... > The idea I though of last night was to have the GC special case certain > objects. It could know about tuples. After collecting the first > generation any surviving tuples that don't refer to objects with the GC > flag could be untracked. Just butting in to be obnoxious about that a NULL slot is a disqualifier for untracking too. > We might even generalize it by untracking objects that don't have a > tp_clear method and don't refer to GC objects. How do we know which other objects they refer to? How do we know that the set of objects they refer to will never change? And do we have a reason to believe that any type other than tuples makes a lick of difference <wink>? > BTW, I also looked into the train algorithm last night. It's cool > because it never examines the entire set of objects (unless they all > happen to be a big cyclic garbage struture). Unfortunately I don't > think it can be adapted for Python. Try adapting Python to it <wink>. [Guido] >> I'd put such code in tuplevisit (assuming it's safe to call GC_UnTrack >> there). > That would be slick. I don't know if it's safe without looking at the > code but it could probably be made so. I believe it would be easy, requiring minor rewrites of all the gc loops that invoke tp_traverse (the gc->gc.gc_next field they rely on to get "the next guy" in the list could go NULL on them across tp_traverse calls).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4