# HG changeset patch
# User Georges Racinet <georges.raci...@octobus.net>
# Date 1619274605 -7200
# Sat Apr 24 16:30:05 2021 +0200
# Branch stable
# Node ID 11011fd630710cce991c9deb949ae85a85651b9a
# Parent 46db86edf8f279063d6f9d5dd673dc88da8b83cf
# EXP-Topic memleak-repo-class
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.
diff -r 46db86edf8f2 -r 11011fd63071 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()
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
