Sage: Ticket #18426: Memory leaks in RootSystem
https://trac.sagemath.org/ticket/18426
<p>
<code>RootSystem</code> is currently creating memory leaks in the following way:
</p>
<p>
Upon creating a root system, say of type B3, this line:
</p>
<pre class="wiki">self.dual = RootSystem(self._cartan_type.dual(), as_dual_of=self);
</pre><p>
causes the B3 root system to be used as a key in the <code>UniqueRepresentation</code> of the C3 root system (I call it so, but note it is the dual of the B3, which will be different than the honest C3 root system), which is a strong reference that can never be deleted. Moreover, the B3 root system then holds a (strong) reference to the C3 root system, so the C3 root system never gets collected either.
</p>
<p>
Some data:
</p>
<pre class="wiki">sage: from collections import Counter
sage: import gc
sage: gc.collect()
349
sage: pre = {id(a) for a in gc.get_objects()}
sage: get_memory_usage()
8697.9453125
sage: for n in range(5, 3000):
....: RS = RootSystem(['A', n])
....:
sage: gc.collect()
106
sage: get_memory_usage()
8703.08984375
sage: post = Counter(str(type(a)) for a in gc.get_objects() if id(a) not in pre)
sage: sorted([p for p in post.items() if p[1] > 2000])
[("<class 'dict'>", 6123),
("<class 'sage.combinat.root_system.root_system.RootSystem'>", 5985),
("<class 'sage.combinat.root_system.type_A.CartanType'>", 2991),
("<class 'tuple'>", 30460),
("<class 'weakref.KeyedRef'>", 9003)]
</pre>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/18426
Trac 1.1.6tscrimFri, 15 May 2015 15:22:20 GMTdescription changed
https://trac.sagemath.org/ticket/18426#comment:1
https://trac.sagemath.org/ticket/18426#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/18426?action=diff&version=1">diff</a>)
</li>
</ul>
<p>
One possible workaround is to not accept a root system as input, but instead a boolean. Then when it creates the dual root system, and then explicitly sets the <code>dual</code> attribute of the dual root system to <code>self</code>.
</p>
TicketnthieryFri, 15 May 2015 15:30:55 GMTdescription changed
https://trac.sagemath.org/ticket/18426#comment:2
https://trac.sagemath.org/ticket/18426#comment:2
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/18426?action=diff&version=2">diff</a>)
</li>
</ul>
<p>
Hi Travis!
</p>
<p>
I am sure there are plenty of other similar situations of cross-referencing parents (e.g. in <code>SymmetricFunctions</code>). How critical do you think this specific situation is? I mean: do you foresee people creating thousands of different root systems in the same Sage session?
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TickettscrimFri, 15 May 2015 15:49:52 GMT
https://trac.sagemath.org/ticket/18426#comment:3
https://trac.sagemath.org/ticket/18426#comment:3
<p>
I'm not so sure about how frequent we get the cross-referencing parents with one of them being a key for a <code>UniqueRepresentation</code>. Although it's hard to tell because there are known memory leaks with the category <code>Algebras</code> that would keep parents alive.
</p>
<p>
For this particular situation, I doubt anyone will create thousands of root systems. What I'm a little worried about is all the different things a root system might keep alive and could pile up (like root lattices (and say you tested them over a large range of finite fields, but this might not be mathematically reasonable), Cartan types/matrices, etc.).
</p>
TicketnbruinFri, 15 May 2015 16:23:19 GMT
https://trac.sagemath.org/ticket/18426#comment:4
https://trac.sagemath.org/ticket/18426#comment:4
<p>
Questions:
</p>
<ul><li>do you really need <code>RootSystem</code> to be <code>UniqueRepresentation</code> (i.e., do these things really participate in the coercion framework)? I would think the "parent" component of a <code>RootSystem</code> is only there because mathematically it looks like something that has elements, not as something whose elements will be interacting with elements from other parents.
</li><li>do you really need <code>RootSystem</code> to hold any references to other root systems? Doesn't the <code>UniqueRepresentation</code> cache provide fast enough access?
</li><li>can you key the <code>UniqueRepresentation</code> via lower level information, e.g., a sequence of integers or so? By changing to a <code>UniqueFactory</code> instead, you could still offer the same interface.
</li></ul><p>
Especially because these things probably happen all over the place, I think it's really good that you're trying to see what kind of solution strategies work well. I'm sure your experience in this can be used in lots of other places. It's hard to predict what people will be doing with the code, so we should try to not make assumptions and unnecessarily restrict usage scenarios.
</p>
TicketslelievreFri, 09 Oct 2020 13:41:12 GMTcc, description changed
https://trac.sagemath.org/ticket/18426#comment:5
https://trac.sagemath.org/ticket/18426#comment:5
<ul>
<li><strong>cc</strong>
<em>slelievre</em> added
</li>
<li><strong>description</strong>
modified (<a href="/ticket/18426?action=diff&version=5">diff</a>)
</li>
</ul>
Ticket