#715: Parents probably not reclaimed due to too much caching
--------------------------------+-------------------------------------------
Reporter: robertwb | Owner: somebody
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.8
Component: coercion | Keywords: weak cache coercion
Work_issues: avoid regression | Upstream: N/A
Reviewer: | Author: Simon King
Merged: | Dependencies: #9138, #11900
--------------------------------+-------------------------------------------
Comment(by SimonKing):
Hi Jean-Pierre,
Replying to [comment:83 jpflori]:
> But if you store the actions in both parents (with strong references),
you will never be able to free any of the two domain and codomain.
This is not necessarily the case. You would merely get circular
references, and they would not obstruct garbage collection, unless one
item in the cycle has a `__del__` method.
One problem, however, is that many actions start with `ZZ`. And if `ZZ` is
contained in the cycle, then it can not be collected, since `ZZ` will live
forever -- but you know that.
> In the ticket example for example you would get a strong reference to
the action in the ZZ cache (which will hopefully never get deleted) (in
fact that is what is happening with the current Sage version anyway, isn't
that strange according to what you posted, because I guess is already
initialized once the for loop is executed?)
Yes. And is it really sure that the actions are stored in `ZZ`?
Anyway. They are stored by `==`, and thus only one copy remains alive.
> so the elliptic curves (in the ticket example you only get one stored in
that cache because comarison was made with "==", if you let the j
invariant change within the for loop you would get a growing number of
curves in that cache) will stay strongly refed forever as well...
Yes. And that is a problem that, again, might be solved using weak
references.
Namely:
Consider an action A of G on S. Typically, G is immortal (like `ZZ`), but
we are willing to let A and S die if we do not have any "external" strong
reference to S. In particular, the existence of A should not be enough to
keep S alive.
I think this can be accomplished as follows:
* For quick access and for backwards compatibility, we want that actions
remain stored in the coercion model. We use weak references to the keys
(G,S), but a strong reference to the action (this is what the previous
version of [attachment:trac715_two_tripledicts.patch] did).
* In addition to that, A should only have a weak reference to S; I think
it doesn't matter whether the reference from A to G is strong or weak.
Let us analyse what happens with G, S and A:
1. G will remain alive forever, even without an external reference.
Namely, the coercion cache has a strong reference to A; as a functor, A
points to `Groupoid(G)`; `Groupoid(G)` is strongly cached (unless we use
weak caching for `UniqueRepresentation`) and must have a reference to G.
If we decide to use weak caching for `UniqueRepresentation`, then we would
only have a strong reference from G to A and a weak or strong reference
from A to G. That would be fine for garbage collection. Anyway, I think
keeping G alive will not hurt.
2. Assume that there is no external reference to S. There is a weak
reference to S from the cache in the coercion model, namely as key of the
cache. Moreover, there is another ''weak'' reference from A to S. Hence, S
could be garbage collected.
3. Assume that there is no external reference to A. If S is garbage
collected (see the previous point), then it will remove itself from the
coercion cache, and thus the strong reference to A would vanish - it could
be collected. But if S is alive, then A will remain alive as well.
However, this is how the experimental patch should work - and it does
''not'' fix the leak. Perhaps this is, again, due to caching the homsets?
So, we would need the patch from #12215 as well. Difficult topic.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/715#comment:86>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
