repoview: separate concerns in _filteredrepotypes comment stable
authorGeorges Racinet <georges.racinet@octobus.net>
Sat, 24 Apr 2021 16:30:05 +0200
branchstable
changeset 47011 b7e623ac98b6
parent 47010 76ae43d5b1db
child 47013 222a42ac5b2d
repoview: separate concerns in _filteredrepotypes comment The cited issue in Python bugtracker is closed, but hasn't been fixed. We've been able to use the attached example and reproduce it with Python 3.9. The point where it turns from needless stress on the GC to the an actual leak is when one factors in the fact that the GC was before Python 3.4 unable to collect some types (see PEP 442). Note that even with Python 2.7, the simple example of cycles due to __mro__ are collectable. This was seen again with the example attached on the CPython issue.
mercurial/repoview.py
--- a/mercurial/repoview.py	Fri Apr 23 18:30:53 2021 +0200
+++ b/mercurial/repoview.py	Sat Apr 24 16:30:05 2021 +0200
@@ -464,9 +464,10 @@
         return delattr(self._unfilteredrepo, attr)
 
 
-# Python <3.4 easily leaks types via __mro__. See
-# https://bugs.python.org/issue17950. We cache dynamically created types
-# so they won't be leaked on every invocation of repo.filtered().
+# Dynamically created classes introduce memory cycles via __mro__. See
+# https://bugs.python.org/issue17950.
+# This need of the garbage collector can turn into memory leak in
+# Python <3.4, which is the first version released with PEP 442.
 _filteredrepotypes = weakref.WeakKeyDictionary()